推荐 序 一 


文 以 载 道 “ 书 以 自 娱 


化 松 的 新 书 付 梓 ， 嘱 我 为 序 ， 品 读 精华 章节 ， 览 其 前 言 ， 心 有 所 感 ， 送 言 而 记 之 。 


关于 写作 之 因由 ， 于 作者 来 说 ， 一 直 是 最 为 重要 的 缘起 。 


认真 地 写作 一 本 好 书 ， 其 中 的 坚持 、 勤 够 、 钻 研 对 于 作者 来 说 都 是 极 大 的 考验 ， 所 以 古人 说 摩 不 有 初 ， 鲜 克 有 终 ， 修 松 完成 了 这 本 书 ， 恭 喜 他 。 


作者 在 前 言 中 提 及 ， 其 实 写 这 本 书 是 他 内 心 积 揭 多 年 的 情节 所 在 ， 我 也 曾 听 其 屡 展 言及 ， 虽 有 所 期 ， 但 是 未 望 其 果 。 今 日 书 成 ， 方 知 作者 坚持 终 未 放弃 ， 此 诚 可 贵 。 


然而 写作 一 本 既 可 以 自 娱 ， 又 可 以 载 道 的 作品 就 又 难 上 加 难 ， 尤 其 是 今日 Oracle 技 术 书籍 几乎 汗 牛 充 栋 ， 这 一 挑战 绝对 不 容 小 凯 。 


匠心 独 运 ， 让 读者 眼前 一 亮 ， 书 中 第 一 部 分 ， 于 Oracle 数 据 库 的 技术 细节 仪 选取 有 关 索 引 设计 、 表 设计 、 优 化 器 等 核心 部 分 ， 我 相信 这 也 是 作者 最 有 心得 的 部 分 ， 所 谓 


纵 观 修 松 大 作 ， 其 结构 设计 堪 称 
展 的 技术 体系 ， 包 括 了 TT、GG、DG 等 知识 〈 国 内 书籍 在 TT、GG 方 面 几乎 空白 ) ， 作 者 从 架构 入 


授 人 以 长 ， 读 者 必 能 从 他 十 数 年 的 经 验 中 体会 Oracle 的 核心 技术 ; 而 书 的 第 二 部 分 涉及 了 Oracle 纵 横 扩 ， 
手 ， 取 Oracle 延 展 的 核心 产品 和 解决 方案 ， 以 自己 在 金融 领域 的 实践 为 依托 ， 娓 九 演 绎 出 来 。 


如 此 两 两 结合 ， 内 取 Oracle 核 心 技 术 ， 外 取 延 展 核心 产品 ， 理 论 与 实践 相 结 合 ， 紧 扣 书 旨 之 架构 之 意 。 


以 此 框架 与 立意 而 论 ， 业 内 尚未 有 与 此 绝 类 之 书 ， 相 信 读 者 可 以 从 中 获得 更 为 宏观 的 技术 视野 和 实践 经 验 ， 如 此 则 不 负 作者 孜孜 之 作 ， 拳 源 之 义 。 


我 从 作者 的 认真 和 经 验 之 中 ， 收 获 良 多 ， 感 谢 作 者 。 
盖 国 强 


云 和 思 墨 创始 人 ，Ortracle ACE 总 监 


推荐 序 二 


FF 前， 初次 与 修 松 见面 还 是 刚刚 大 学 毕业 进入 公司 时 ， 他 正 端 坐 在 台 前 认真 地 编写 代码 。 彼 时 和 他 还 不 在 一 个 部 门 工作 ， 但 是 对 他 的 技术 和 工作 态度 早 有 耳闻 ， 后 来 有 幸 和 他 一 起 为 公司 开发 


还 记得 109 
FIT。 当 时 系统 的 后 台数 据 库 是 Oracle， 按 照 规定 我 们 这 样 的 菜鸟 是 不 能 直接 操作 数据 库 的 ， 即 使 出 现 问题 也 要 找 外 籍 专家 来 解决 ，Oracle 给 了 我 


ERP 系 统 ， 他 严谨 而 灵活 的 思维 让 我 觉得 他 天 生 就 应 该 属 了 
们 高 大 上 的 第 一 印象 。 


这 家 公司 虽 大 ， 奈 何 对 刚刚 走出 校园 、 渴 望 知 识 的 我 们 在 技术 提升 方面 实在 有 限 ， 几 个 人 闲 下 来 总 在 讨论 如 何 找到 出 路 ， 想 来 每 个 年 轻 人 都 会 经 过 这 个 阶段 。 当 时 初生 牛犊 ,没有 经 过 太 多 的 犹 聊 ， 选 
择 了 Oracle 这 条 道路 。 时 至 今日 看 来 ，Oracle 为 我 们 带 来 的 除了 还 算 顺 利 的 职场 生涯 ， 也 使 平时 工作 中 的 思维 模式 有 所 改变 ，Oracle 架 构 体系 之 复杂 ， 设 计 理 念 之 先进 ， 即 使 在 分 布 式 ， 开 源 技术 大 行 其 道 


今 


的 今天 仍然 在 工作 中 给 到 我 大 量 的 启示 ， 让 我 对 于 其 他 IT 技术 能 够 做 到 触 类 旁 通 。 在 这 里 也 想 告诉 正在 寻找 方向 的 T 人 ， 热 爱 你 的 选择 ， 一 条 路 走 到 黑 ， 做 到 行业 顶尖 ， 一 定 会 有 回报 的 。 
， 这 本 书 在 技术 和 行业 经 验方 面 一 定 能 够 


市 面 上 Oracle 书 籍 甚 多 ， 然 抄 文档 、 炒 冷 饭 、 二 把 刀 翻 译 书 层出不穷 ， 能 称 得 上 原创 和 精品 的 密 察 无几， 涉及 金融 保险 业内 一 些 技术 解决 方案 的 更 是 凤 毛 锯 f 
给 广大 读者 以 帮助 。 


a 


DeNA China 运 维 总 监 


加 
囊 


为 什么 要 写 这 本 书 


我 总 结 和 快乐 分 享 的 初衷 ， 不 只 一 次 地 咨询 过 eygle 大 师 关 于 写 书 的 细节 ，eygle 大 师 也 热情 地 予以 指导 。 遗 憾 的 是 ， 总 是 


写 一 本 Oracle 数 据 库 方面 的 技术 书籍 ， 是 我 一 个 持续 了 四 五 年 的 想法 。 本 着 
为 这 样 那样 的 原因 ， 这 个 想法 迟 迟 不 能 落地 。 


2013 年 的 夏天 ， 我 有 幸 作为 微 博 特 使 参与 了 甲骨 文 全 球 大 会 (Oracle Open World) 上 海 站 的 活动 ， 跟 一 位 甲骨 文 的 朋友 闲谈 中 ， 不 经 意 聊 到 了 与 Oracle 数 据 库 “共事 ”已 经 快 十 年 了 。 朋 友 说 我 应 该 
有 不 少 心得 了 ， 鼓 励 我 花 一 年 的 时 间 来 做 一 个 总 结 ， 可 以 写 一 本 书 分 享 给 更 多 的 朋友 。 “十 年 ”是 一 个 非常 特别 的 东西 ， 它 彻底 激发 出 我 写 书 的 热情 。 凌 乱 的 思绪 ， 不 知 该 写 些 什么 的 时 候 ， 联 想到 再 游 十 


年 未 见 西湖 的 感触 : 


云 忧 风 氛 山北 暮 ， 桥 断 平 湖 ， 西 子 颜 如 故 。 曲 院 风 荷 香 瞳 渡 ， 余 晖 昨日 穿 朱 户 。 


月 洲 星 稀 闻 浪 住 ， 对 酒 当 歌 ， 言 莫 悉 时 苦 。 意 若 随心 晴 若 雨 ， 谁 知 明日 渔 归 处 ? 


对 于 技术 人 来 说 ， 杭 州 渐渐 演变 成 技术 之 城 ， 然 而 因为 西湖 ， 她 应 该 是 艺术 的 。 正 如 以 艺术 之 眼 去 欣赏 Oracle 数 据 库 ， 不 仅仅 是 纯 技术 活 ， 更 能 发 现 其 艺术 之 美 。 怀 着 一 颗 附庸 风雅 之 心 ， 我 决定 写 一 
本 具有 一 定 实用 价值 的 数据 库 架 构 设 计 和 性 能 优化 方面 的 书 。 


视 了 ， 然 而 我 一 直 认 为 OCP 给 我 们 提供 了 一 个 
因为 一 些 基础 的 概念 性 的 东西 而 纠结 


回顾 十 年 技术 之 路 ， 如 大 多 数 同行 一 样 ， 一 切 都 是 从 OCP 认 证 开始 的 ， 没 能 赶 上 8i OCP 的 末班车 ， 只 好 搭乘 了 9i OCP 的 头 班车 。 如 今 认证 不 如 以 前 受 本 
完整 的 基础 知识 体系 ， 其 价值 不 在 于 那 一 张 纸 而 已 。 现 在 ，DBA 工 作 内 容 逐 步 实现 了 流程 化 和 模块 化 ， 一 些 初学 者 已 经 可 以 轻松 地 完成 一 些 复杂 架构 的 搭建 ， 却 时 常会 
不 清 ， 我 会 毫 不 犹 移 地 推荐 他 们 去 进行 OCP 教 材 的 学 习 。 只 有 建立 自己 的 基础 知识 体系 ， 才 能 主动 地 去 思考 问题 ， 才 能 开始 专职 DBA 之 路 。 


在 十 年 之 前 ， 有 专职 DBA 的 公司 可 以 说 少 之 又 少 ， 早 期 的 DBA 都 是 从 开发 转 过 来 的 ， 做 的 人 多 了 ， 也 就 有 专职 DBA 这 个 概念 ， 进 而 很 多 不 愿意 写 代码 的 人 也 纷纷 投身 其 中 。 各 个 公司 也 出 于 系统 安全 和 
精细 分 工 的 考虑 ， 开 始 禁 止 DBA 了 解 、 熟 悉 业 务 ， 禁 止 DBA 访 问 业务 数据 等 ， 以 至 于 现在 很 多 DBA 没 有 开发 能 力 ， 也 不 懂得 业务 应 用 ， 仅 仅 是 一 个 数据 库 技术 的 支持 者 ， 进 而 导致 DBA 被 误 读 为 夕阳 职业 。 
早期 的 DBA 为 什么 能 备 受 重视 ， 不 仅仅 是 因为 物 以 稀 为 贵 ， 更 多 的 是 因为 有 开发 背景 ， 了 解 业务 流程 ， 具 备 复合 能 力 ， 这 才 是 最 可 贵 的。 可 以 说 不 懂得 DBA 技 能 的 开发 不 是 好 开发 ， 不 懂得 开发 的 DBA 不 是 
好 DBA。 


可 喜 的 是 ， 随 着 时 间 的 发 展 ， 大 家 都 开始 意识 到 这 个 问题 ， 于 是 数据 库 架 构 师 的 概念 应 运 而 生 ， 他 们 是 一 群 复 合 能 力 的 拥有 者 ， 是 开发 人 员 和 DBA 之 间 的 桥梁 。 然 而 ， 复 合 能 力也 是 有 较 强 的 行业 依赖 
性 的 ， 没 有 可 以 跨行 业 的 万 能 复合 ， 也 没有 能 完全 跨行 业 实现 的 万 能 数据 库 架构 。 我 在 本 书 的 编写 过 程 中 ， 也 是 以 我 熟悉 的 金融 行业 为 立足 点 ， 尽 可 能 地 兼顾 全 面 阐述 。 


本 书 将 给 读者 一 个 全 新 的 视角 ， 秉 承 大 道 至 简 的 主导 思想 ， 只 介绍 高 并 发 数据 库 架 构 设计 中 最 值得 关注 的 内 容 ， 不 在 于 某 种 技能 的 分 享 ， 而 致力 于 一 种 方法 论 的 建立 ， 希 望 能 抛砖引玉 ， 以 个 人 的 一 些 
想法 和 见解 ， 为 读者 拓展 出 更 深入 、 更 全 面 的 思路 。 


本 书 特色 


从 技术 层面 上 讲 ， 本 书 首次 介绍 了 国外 已 经 成 熟 使 用 ， 而 国内 方兴未艾 的 TimesTen (简称 TT) 和 GoldenGate (简称 GG) 。TimesTen 作 为 一 款 基 于 内 存 的 关系 型 数据 库 ， 同 时 兼顾 了 内 存 处 理 的 快速 
和 传统 数据 库 的 稳定 ， 更 具备 了 与 Oracle 数 据 库 的 无 颖 衔接 ， 对 于 日 趋 增长 的 数据 库 并 发 量 和 即时 响应 速度 要 求 ， 其 将 大 有 用 武之 地 ; GoldenGate 一 度 被 誉 为 数据 复制 、 集 成 、 迁 移 、 容 灾 之 神器 ， 在 国 
内 也 开始 风靡 ， 本 书 将 揭示 其 核心 特点 及 优势 前 景 。 另 外 ，Oracle 数 据 库 的 技术 细节 仅 选 取 有 关 索 引 设计 、 表 设计 、 优 化 器 等 部 分 ， 只 讲述 最 核心 的 技术 ， 以 激发 读者 的 联想 ， 进 而 衍化 至 繁 。 


从 适合 读者 阅读 和 掌握 知识 的 结构 安排 上 讲 ， 分 为 “内 政 篇 " 和 “纵横 篇 ” 。“ 内 政 篇 ” ，Oracle 技 术 方面 的 优化 ， 很 多 资料 只 是 介绍 如 何 做 ， 却 鲜 有 介绍 为 何 这 样 做 ， 本 篇 将 让 读者 知 其 所 以 然 ， 也 
是 作者 自身 经 验 的 一 些 总 结 。“ 纵 横 篇 ”，TimesTen 对 很 多 Oracle 从 业 人 员 而 言 基 本 上 是 只 闻 其 名 ， 不 知 其 味 的 。 在 与 淘宝 、 支 付 宝 同行 交流 中 ， 大 家 都 觉得 好 ， 但 是 因为 不 了 解 而 不 用 。 本 篇 将 给 大 家 展 
开 一 个 活生生 的 TimesTen 应 用 指导 。 


本 书 就 是 从 Oracle 内 部 扩展 、 纵 向 扩展 (TimesTen) 、 横 向 扩展 (GoldenGate、ADG) 三 个 维度 为 读者 展开 讨论 ， 深 入 分 析 ， 并 提供 相应 的 解决 方案 。 


本 书 中 一 些 实 操 的 例子 和 章节 ， 比 较 适 合 DBA、 程 序 员 ， 可 以 成 为 工作 手边 书 ; 架构 设计 和 深入 分 析 方面 的 章节 ， 比 较 适合 架构 师 、BA、IA， 可 以 分 享 经 验 ， 拓 展 解决 问题 的 思路 ;工具 和 产品 的 应 
场景 定位 等 ， 更 适用 于 CTO、CIO 对 技术 市 场 前 景 的 把 握 。 


读者 对 象 


We 
3 


据 库 架构 师 


“ 数据库 管 理 员 


“ 开发 应 用 架构 师 


“ 数据 库 开 发 人 员 


“ 数据 库 相关 的 管理 人 员 


此 


“ 其 他 对 数据 库 技术 感 兴趣 的 人 员 


如 何 阅读 本 书 


本 书 分 为 两 大 部 分 ， 共 计 9 章 内 容 。 


第 一 部 分 为 “内 政 篇 ”， 着 重 讲解 Oracle 数 据 库 内 部 的 架构 设计 优化 和 扩展 ， 包 括 以 下 5 章 内 容 : 


第 1 章 “从 实际 问题 出 发 ， 讨 论 现 下 流行 的 架构 设计 思路 ， 并 提出 大 道 至 简 的 架构 理念 ， 以 数据 库 森 林 体系 为 基础 ， 展 开 高 并 发 Oracle 数 据 库 的 架构 设计 方法 论 。 


第 ? 章 ”详细 介绍 索引 扫描 方式 ， 索 引 对 排序 过 程 的 意义 ， 索 引 设计 的 方法 与 技巧 ， 并 深入 剖析 索引 树 分 裂 生 长 原理 和 索引 维护 方法 。 


第 3 章 ”详细 介绍 表 设 计 中 字段 类 型 选择 、 字 段 顺序 、 分 区 表 使 用 、 匈 余 手 段 、 数 据 生命 周期 管理 等 问题 ， 以 及 行 链接 、 行 迁移 、 碎 片 管理 等 表 结构 维护 手段 。 


第 4 章 ”详细 介绍 了 优化 器 的 种 类 ， 配 置 管理 方法 ， 成 本 计算 原理 ， 统 计 信息 的 收集 管理 策略 ， 执 行 计划 管理 ， 以 及 基于 Oracle 工 具 的 数据 库 性 能 影响 分 析 。 


第 5 章 ” 从 实际 案例 出 发 ， 详 细 介 绍 锁 相关 问题 (包括 Lock、Latch、Mutex 等 ) 的 高 并 发 案例 ， 以 及 REDO 相 关 的 MO、 进 程 、 等 待 事件 的 分 析 。 


第 二 部 分 为 “纵横 篇 ”， 着 重 讲解 基于 Oracle 数 据 库 的 纵向 和 横向 扩展 的 架构 设计 ， 包 括 以 下 4 章 内 容 : 


第 6 章 详细 、 深 入 地 介绍 了 Oracle 的 一 款 内 存 数据 库 TimesTen 的 前 世 今生 、 安 装配 置 技巧 、 缓 存 应 用 、 高 可 用 架构 设计 ， 以 及 基础 对 象 的 设计 与 管理 。 并 从 实际 运 维 出 发 ， 介 绍 TimesTen 的 典型 监控 


方法 ， 数 据 备份 恢复 与 数据 迁移 方法 。 最 后 结合 实际 高 并 发 场景 ， 对 TimesTen 进 行 评估 与 对 比 测试 。 


总 


第 7 章 “展开 介绍 使 用 GoldenGate 的 安装 配置 和 监控 ， 并 结合 链 路 原理 的 实现 ， 拓 展 数据 集成 平台 和 异 构 数据 库 群 的 设计 思路 。 


第 8 章 ， 主 要 围绕 Data Guard 功 能 ， 介 绍 了 “T-1” 交易 数据 库 和 ADG 数 据 库 两 种 新 型 的 应 用 方式 ， 拓 宽 了 Data Guard 功 能 的 使 用 范围 ， 使 得 其 不 仅仅 是 典型 容 灾 解决 方案 ， 更 能 为 解决 高 并 发 问题 发 
挥 积极 作用 。 


第 9 章 “” 带 给 读者 一 个 总 结 性 的 整体 介绍 ， 并 简单 介绍 一 些 超出 纯 技术 范围 的 软 技巧 。 


其 中 ， 第 2 章 、 第 3 章 、 第 4 章 和 第 6 章 为 本 书 的 重点 章节 ， 如 果 你 没有 充足 的 时 间 完 成 全 书 的 阅读 ， 可 以 选择 性 地 进行 重点 章节 的 阅读 。 如 果 你 是 一 位 有 着 一 定 经 验 的 资深 和 人员， 本 书 可 能 会 是 一 本 不 错 
的 案 前 书 。 然 而 ， 如 果 你 是 一 名 初学 者 ， 请 在 开始 本 书 阅读 之 前 ， 先 进行 一 些 数据 库 的 基础 理论 知识 的 学 习 。 


勘误 和 支持 


由 于 作者 的 水 平 有 限 ， 编 写 时 间 仓 促 ， 书 中 难免 会 出 现 一 些 错误 或 者 不 准确 的 地 方 ， 妨 请 读者 批评 指正 。 如 果 您 有 更 多 的 宝贵 意见 ， 欢 迎 您 访问 我 的 个 人 网 站 http://www.housong.net 进 行 专题 讨 
论 ， 我 会 尽量 在 线 上 为 您 提供 最 满意 的 解答 。 同 时 ， 您 也 可 以 通过 微 博 @ 麻 袋 爸 爸 ， 或 者 邮箱 houalex@gmailcom 联 系 到 我 ， 期 待 能 够 得 到 你 们 的 真挚 反馈 ， 在 技术 之 路 上 互 勉 共 进 。 


感谢 Oracle 官 方 文档 ， 在 写作 期 间 提供 给 我 最 全 面 、 


感谢 大 仙 、 子 夜 流星 两 位 好 友 ， 在 我 写作 出 现 迷 惑 的 时 候 ， 予 以 帮助 和 指导 。 


感谢 Tom Kyte、Jonathan Lewis、Tanel Poder 等 多 位 大 师 ， 以 及 ITPUB 和 CSDN 社 区 的 各 位 技术 专家 们 的 博客 文章 ， 每 次 阅读 必 有 所 获 ， 本 书 也 多 处 引 


感谢 机 械 工业 出 版 社 华章 公司 的 首席 策划 杨 福 川 和 编辑 高 婧 牙 ， 在 近 一 年 的 时 间 中 始终 支持 我 的 写作 ， 你 们 的 鼓励 和 帮 


特别 致谢 


最 后 ， 我 要 特别 感谢 我 的 太太 Liven 和 女儿 ， 我 为 写作 这 本 书 ， 牺 和 性 了 很 多 陪伴 她 们 的 时 间 ， 但 也 正 因为 有 了 她 们 的 付 t 


最 深入 、 最 准确 的 参考 材料 ， 强 大 的 官方 文档 支持 也 是 其 他 数据 库 所 无 法 企及 的 。 


助 引导 我 顺利 完成 全 部 书稿 。 


与 支持 ， 我 才能 坚持 写 下 去 。 


同时 ， 感 谢 我 的 父母 、 岳 父 岳母 ， 特 别 是 我 的 岳母 ， 不 遗 余 力 地 帮助 我 们 照顾 女儿 ， 有 了 你 们 的 帮助 和 支持 ， 我 才 有 时 间 和 精力 去 完成 写作 工作 。 


说 以 此 书 献 给 我 最 亲爱 的 


万 物 之 始 ， 大 道 至 简 ， 衍 


万 物 之 始 ， 大 道 至 简 ， 衍 化 至 繁 。 世 间 一 切 事物 在 刚刚 开始 的 时 候 ， 都 是 非常 简单 的 ， 是 为 大 道 ， 随 着 事物 不 断 地 发 展 ， 


家 人 ， 以 及 众多 热爱 数据 库 技术 的 朋友 们 ! 


第 一 部 分 ”内政 篇 


化 至 繁 。 


左右 事物 的 还 是 那些 最 基本 的 东西 一 一 大 道 。 如 果 能 牢 牢 把 握 住 这 些 被 认 作 是 “大 道 ” 的 东西 ， 再 复杂 的 局 面 也 自然 会 变 得 简单 。 


之 复杂 就 像 将 要 开启 一 个 新 的 


近 些 年 来 ， 在 数据 库 领域 里 ， 可 谓 群 雄 逐 应 ， 志 在 中 原 。 
杂 


他 们 各 自 有 各 自 的 特色 ,相互 间 也 甚 是 喜欢 


时 代 。 不 论 是 作为 研发 者 还 是 


为 什么 会 有 如 此 多 样 的 数据 库 在 市 场 上 竞争 呢 ? 当然 是 市 场 需求 在 推动 的 ， 而 需求 的 本 身 则 源 自 于 各 行业 的 业务 系统 应 


的 时 代 ， 其 中 的 佼佼 者 无 疑 还 是 Oracle 数 据 库 。 


本 书 将 秉承 大 道 至 简 的 主 


1.1 初 见 高 并 发 


高 并 发 这 个 概念 并 不 新 鲜 
往 是 读 和 写 会 交织 在 一 起 ， 并 


这 个 时 候 ， 相 信 很 多 读者 : 


了 他 们 的 观点 和 思想 。 


修 松 


一 老子， 


《道德 经 》 


I 


自己 的 长 处 去 比较 对 手 的 短处 ， 以 彰显 其 产品 的 优势 ， 眼 花 练 乱 的 测试 结果 和 市 场 评价 ， 其 局 面 
户 ， 这 样 的 竞争 无 疑 都 是 一 件 好 事 ， 但 也 要 求 我 们 需 懂得 把 握 其 中 的 大 道 。 


3 思想， 立足 于 Oracle 的 数据 库 相关 技术 ， 给 读者 展示 一 套 高 并 发 业务 系统 的 数据 库 架 构 设计 方法 论 。 


， 可 以 说 有 数据 库 的 地 方 都 有 可 能 面临 高 并 发 的 问题 。 在 数据 库 里 ， 高 并 发 问题 主要 集中 在 两 个 方 


同时 呈现 出 高 并 发 的 问题 。 


的 过 程 中 ， 不 能 驻足 于 技术 层 
架构 师 的 分 析 能 力 和 沟通 能 力 


其 衍 变 出 来 各 种 复杂 的 局 面 。 然 而 ， 追 本 溯源 ， 仍 然 会 发 现 复杂 局 面 下 真正 在 


。 如 果 说 未 来 会 开启 一 个 新 数据 库 时 代 ， 那 很 好 。 然 而 ， 现 在 无 疑 还 是 RDBMS 


面 : 读 的 高 并 发 、 写 的 高 并 发 ， 两 者 看 起 来 都 不 是 很 复杂 


然而 实际 情况 往 


都 会 提出 一 个 观点 : 做 读 写 分 离 嘛 。 是 的 ， 这 是 一 个 不 错 的 主意 ， 但 只 是 一 个 治标 不 治本 的 主意 。 业 务 系统 的 耦合 度 很 高 ， 是 不 可 能 实现 业务 层级 的 读 写 分 离 的。 在 架构 设计 


面 ， 还 是 需要 渗透 到 业务 层面 去 的 。 不 论 是 业务 驱动 技术 ， 还 是 技术 驱动 业务 ， 两 者 都 是 不 能 分 离开 考虑 的 ， 比 较 好 的 做 法 应 该 是 ， 在 两 者 之 间 形 成 一 种 平衡 ， 当 然 这 是 需要 


来 加 以 驱动 的 。 


一 些 资源 ， 比 如 数据 块 、 索 引 块 、Latch 和 Mutex。 表 现 出 很 多 等 待 事件 的 冲 高 。” 


1.1.1 ”从 一 次 谈话 说 起 
应 用 架构 师 : “哥们 ! 还 记得 上 半年 让 你 们 帮忙 做 的 一 次 数据 库容 量 测试 吗 ?“ 
数据 库 架 构 师 : “当然 ! 我 们 可 是 费 了 很 大 的 工夫 才 完 成 的 。” 
应 用 架构 师 : “当时 不 是 说 我 们 在 现 有 的 硬件 条 件 下 ， 数 据 库 的 容量 足够 承受 当时 4 倍 业务 压力 吗 ? 可 是 下 半年 我 们 的 业务 量 才 增 长 了 0.5 倍 ， 怎 么 就 不 行 了 呢 ?“ 
数据 库 架 构 师 : “从 系统 资源 利用 率 的 报告 来 看 ，CPU、 内 存 、I/O、 网 络 上 都 没有 太 大 的 压力 。 但 是 ， 在 业务 高 峰 时 段 ，CPU 出 现 短暂 冲 高 的 现象 。” 
应 用 架构 师 : “ 没 错 ! 在 应 用 端 可 以 看 到 出 现 用 户 阻塞 ， 中 间 件 上 的 连接 持续 增加 ， 没 有 得 到 及 时 释放 。” 
数据 库 架构 师 : “ 嗯 ， 那 是 数据 库 未 能 及 时 响应 造成 的 。CPU 冲 高 ， 通 过 监控 ， 我 们 发 现 很 多 并 发 的 会 话 在 争 | 
应 用 架构 师 : “我 想 我 们 遇 到 高 并 发 争 用 的 麻烦 了 。” 
数据 库 架 构 师 : “是 的 。 当 初 这 套 系统 的 设计 ， 预 期 到 现在 这 么 大 的 业务 压力 了 吗 ?” 
应 用 架构 师 : “ 谁 也 不 会 有 这 种 先 见 之 明 吧 ? 当初 只 是 一 种 业务 的 尝试 而 已 ， 谁 能 想到 市 场 的 反应 会 那么 好 ! 从 数据 库 


层面 来 看 ， 有 什么 好 办 法 吗 ? 毕竟 现在 的 问题 出 在 数据 库 上 。” 


数据 库 架 构 师 : “办 法 是 有 的 ， 针 对 性 地 一 一 解决 掉 。 但 是 ， 这 总 归 是 治标 不 治本 的 办 法 。 就 像 治水 ， 现 在 压力 我 们 堵 住 了 ， 如 果 压 力 再 大 一 些 呢 ? 我 需要 你 的 帮助 。“ 


应 用 架构 师 : “你 是 说 业务 架构 的 变更 吗 ?小 变化 没有 问题 ， 但 是 要 像 互 联网 公司 那样 大 改 ， 肯 定 是 不 行 的 ， 我 们 接受 不 了 这 么 大 的 变化 。” 


数据 库 架 构 师 : “是 的 ， 变 革 对 我 们 来 说 ， 成 本 太 大 ， 小 帆船 掉头 容易 ， 航 母 掉头 可 能 就 要 出 事情 了 。” 


应 用 架构 师 : “我 们 最 近 在 开发 消息 队列 ， 能 一 定 程度 上 缓解 用 户 的 高 并 发 压力 。 但 这 是 以 牺牲 用 户 体验 作为 代价 的 ， 终 归 不 是 太 好 的 办 法 。 


数据 库 架 构 师 : “我 想 我 们 可 以 学 习 大 再 治水 ， 堵 不 上 ， 就 疏通 。 先 将 一 部 分 业务 压力 分 离 出 去 ， 在 子 数据 库 和 主 数据 库 之 间 即 时 同步 必要 的 数据 ， 同 时 适当 郊 余数 据 到 子 数据 库 ， 减 少数 据 库 之 间 的 
交互 。” 


应 用 架构 师 : “是 个 好 办 法 ， 我 们 现在 不 就 是 这 么 在 做 的 吗 ? 问题 不 还 是 在 那里 吗 ?” 


数据 库 架 构 师 : “我 想 是 的 。 因 为 业务 热点 过 于 集中 ， 在 数据 库 上 这 部 分 业务 数据 耦合 度 又 非常 高 ， 没 有 办 法 做 到 有 效 拆 分 。” 


应 用 架构 师 : “这 不 奇怪 ， 我 们 的 业务 逻辑 的 复杂 程度 不 是 互联 网 应 用 可 以 比拟 的 ， 没 办 法 像 他 们 那样 去 充分 地 解 耦 。 但 是 ， 我 们 是 否 可 以 学 习 他 们 使 用 廉价 MySQl 数 据 库 代替 Oracle 数据 库 ， 这 样 业 
务 分 离 的 成 本 就 低 了 很 多 。 


数据 库 架 构 师 : “你 确定 这 样 的 成 本 会 低 吗 ? Oracle 数 据 库 的 开发 人 员 真 的 会 开发 MySQL 吗 ”我 们 的 业务 逻辑 是 很 难 在 MySQL 数 据 库 上 实现 的 ， 现 在 Oracle 数 据 库 帮助 我 们 完成 了 大 部 分 的 数据 耦 
合 ， 如 果 使 用 MySQL， 这 些 都 将 要 在 应 用 端 完成 ， 开 发 成 本 将 会 增加 。 另 外 ，Oracle 有 强大 的 优化 器 机 制 ， 开 发 者 写 得 不 算 太 好 的 SQL， 它 也 能 包容 ，MySQL 则 不 然 了 ，SQL 写 得 不 好 ， 马 上 给 你 颜色 看 ， 
因为 它 的 优化 机 制 不 能 跟 Oracle 相 提 并 论 。 与 Oracle 相 比 ，MySQL 只 能 作为 一 个 数据 容量 来 看 待 。” 


应 用 架构 师 : “你 说 的 这 些 我 也 明白 ， 但 是 我 们 的 数据 库 是 应 该 架构 扩展 了 吧 ?“ 


数据 库 架 构 师 : “当然 。 虽 然 我 们 不 能 做 到 充分 的 数据 解 耦 ， 但 是 一 点 一 点 地 解 还 是 可 以 的 吧 。 我 们 现在 的 问题 是 解决 高 并 发 问题 ， 而 高 并 发 集中 的 那 部 分 业务 就 是 我 们 的 目标 。” 


应 用 架构 师 : “ 那 部 分 业务 很 难 弄 哦 。 读 写 比 例 为 5 : 1， 写 操作 占 比 还 是 蛮 高 的 ， 而 且 都 交织 在 一 起 的 。 最 大 的 问题 是 要 保证 较 快 的 响应 速度 ， 否 则 高 并 发 压力 就 会 积压 。” 


数据 库 架 构 师 : “内 存 数据 库 ! 将 其 作为 Oracle 数 据 库 的 前 置 缓存 数据 库 来 加 快 响应 速度 ， 如 果 保证 了 快速 响应 ， 高 并 发 压力 也 就 解决 了 。 眼 下 Oracle 和 SAP 都 在 内 存 数据 库 上 大 做 文章 呢 。 


应 用 架构 师 : “他 们 都 是 在 摘 OLAP 的 内 存 数据 库 吧 ， 我 们 的 可 是 OLTP。 


数据 库 架 构 师 : “Oracle 的 TimesTen 就 是 为 了 解决 OLTP 的 并 发 问题 而 研发 的 哦 。 关 键 是 看 我 们 的 应 用 是 否 适 应 得 了 。” 


应 用 架构 师 : “ 嗯 ,是 多 样 化 的 数据 库 架 构 了 。” 


数据 库 架 构 师 : “是 的 ， 就 像 一 套数 据 库 生 态 体系 ， 没 有 必要 特别 待 见 谁 ， 也 没有 必要 特别 排斥 谁 ， 关 键 是 看 应 用 的 需要 。 不 过 ， 我 们 也 需要 反思 一 个 问题 ， 就 是 当初 Oracle 的 设计 阶段 没有 预见 性 ， 
应 该 从 Oracle 内 部 设计 先 把 握 好 ， 加 强 其 处 理 并 发 的 能 力 。 是 谓 : “ 先 修 内政 而 后 纵横 。 “ 


1.1.2 “问题 就 在 那里 


~ 


看 过 宛 长 的 对 话 ， 我 们 来 总 结 一 下 吧 ， 问 题 到 底 出 在 哪里 ? 


“ Oracle 数据 库 架构 设计 之 初 ， 粗 放 设 计 ， 没 有 充分 把 握 细 节 ; 


“ 业务 数据 耦合 度 过 高 ， 无 法 充分 解 耦 ， 革 命 性 的 变化 成 本 太 高 ， 不 能 接受 ; 


“ 业务 逻辑 比较 厚重 ， 灵 活性 不 高 ; 


“ 可 以 接受 架构 创新 。 


以 上 问题 ， 相 信 很 多 架构 师 和 数据 库 管理 员 们 都 会 面临 。 更 多 时 候 ， 我 们 都 是 无 力 去 推动 业务 的 ， 让 业务 适应 技术 ， 一 直 都 是 技术 人 员 美 好 的 愿望 ， 却 鲜 有 实现 。 现 实 一 点 地 来 看 ， 我 们 只 能 在 一 定 程 
度 上 去 引导 业务 ， 但 不 能 完全 让 技术 去 适应 业务 ， 两 者 需要 达到 一 种 平衡 。 


立足 于 大 多 数 的 传统 行业 ， 来 看 一 看 应 用 的 现状 吧 。 业 务 逻 辑 都 是 经 年 累 月 沉淀 下 来 的 ， 要 想 做 出 革命 性 的 变化 确实 很 难 ， 除 非 行业 革命 。 谁 能 想象 一 下 ， 让 银行 去 拆 分 核心 还 辑 呢 ? 业务 看 似 刁 难 的 
要 求 ， 也 蕴藏 着 行业 的 特点 ， 架 构 师 是 需要 充分 认识 到 这 一 点 的 。 


如 图 1-1 所 示 ， 理 想 情况 下 的 应 用 系统 架构 中 的 子 系统 应 该 是 相对 比较 独立 的 ， 子 系统 之 间 关 联 较 少 ， 而 且 相 互 关 联 的 子 系统 数量 相对 较 少 。 实 际 情况 往往 是 大 相 径 庭 的 ， 子 系统 之 间 存 在 很 高 的 耦合 
性 。 子 系统 内 读 写 错综复杂 ， 基 本 上 不 可 能 实现 读 写 分 离 。 面 对 这 样 的 现实 ， 出 于 成 本 和 风险 的 考虑 ， 很 难 做 到 子 系统 的 解 厅 ， 理 想 情况 也 只 能 是 理想 了 。 


中 | 


了 于 系统 1 


图 1-1 架构 现状 


业务 子 系统 与 数据 库 的 对 应 关系 ， 如 图 1-2 所 示 。 在 一 套 完整 的 数据 库 生 态 体系 中 ， 子 系统 和 数据 库 也 是 无 法 独立 开 的 。 理 想 情况 是 若干 子 系统 分 布 在 一 个 数据 库 中 ， 数 据 库 基本 上 是 自 包含 的 。 现 实 仍 
然 是 残酷 的 ， 往 往 是 子 系统 和 数据 库 出 现 多 对 多 的 关系 。 


那么 ,数据 库 架 构 设计 就 需要 反映 这 样 的 业务 架构 ， 如 图 1-3 所 示 。 对 于 某 一 系列 的 业务 应 用 来 说 ， 是 不 可 能 通过 单个 数据 库 来 实现 的 。 需 要 的 是 一 个 数据 库 群 ， 其 中 包含 核心 库 、 业 务 应 用 库 ， 以 及 各 
种 功能 的 库 ， 根 据 重要 性 做 层级 划分 。 数 据 库 之 间 实 现 即时 的 数据 同步 ， 构 成 一 套 完整 的 数据 库 生 态 体系 。 


做 到 这 些 是 不 是 就 解决 问题 了 呢 ? 当然 没有 ， 如 果 解 决 了 ， 也 不 会 有 以 上 那 段 对话 。 但 是 ， 这 种 架构 的 演化 方向 是 正确 的 ， 将 错综复杂 的 业务 分 为 治之 ， 如 果 某 些 业务 上 出 现 了 很 高 的 并 发 压力 ， 也 不 
会 影响 到 其 他 业务 的 应 用 ， 还 可 以 将 影响 面 控制 在 最 小 范围 内 。 


虽然 本 次 在 架构 建 模 阶段 没有 充分 考虑 到 Oracle 数 据 库 的 细节 问题 ， 但 是 也 可 以 作为 一 次 经 验 教训 ， 为 下 次 的 建 模 工作 提供 指导 。 可 喜 的 是 ， 我 们 也 不 必 坐 以 待 毕 ， 架 构 的 创新 始终 都 是 受 欢迎 的 ， 因 
为 这 意味 着 数据 库 的 并 发 处 理 能 力 的 提升 。 


图 1-2 子 系统 与 数据 库 的 对 应 关系 


图 1-3 数据库 生态 体系 架构 


从 技术 层面 来 看 待 以 上 的 问题 ， 我 们 可 以 去 做 好 两 件 事情 : 
“Oracle 数 据 库 架构 设计 工作 细 化 ; 


“ 以 Oracle 数 据 库 为 中 心 ， 开 展架 构 纵 横 扩 展 。 


1.1.3 ”你 不 是 一 个 人 在 战斗 


对 于 现在 的 企业 级 应 用 系统 来 说 ,数据 库 一 般 不 会 成 为 一 套 系统 的 瓶颈 所 在 。 数 据 库 出 现 高 并 发 问题 往往 都 是 热点 业务 集中 争 用 造成 的 结果 。 为 什么 这 么 说 呢 ?” 因 为 现在 的 数据 库 应 用 中 ， 不 论 是 
Oracle 数 据 库 ， 还 是 MySQL 数 据 库 ， 抑 或 其 他 新 型 数据 库 ， 它 们 都 不 是 一 个 人 在 战斗 。 


如 图 1-4 所 示 ， 在 一 套 比较 完整 的 应 用 系统 架构 体系 中 ， 一 般 可 以 分 为 四 个 大 层级 : 


“ 应 用 层 : 直接 服务 于 最 终 用 户 的 ， 完 成 用 户 行为 的 交互 。 
“ 网 络 层 : 后 台 处 理 的 第 一 个 层级 ， 实 现 网 络 路 由 ， 并 通过 网 络 负载 均衡 器 实现 第 一 次 负载 均衡 ， 使 高 并 发 压力 第 一 次 得 到 分 流 。 


“ 中 间 件 层 : 就 是 通常 说 的 B/S 架 构 的 中 间 服 务 器 层 ， 其 接收 网 络 层 来 的 用 户 连接 ， 并 实现 第 二 次 负载 均衡 ， 所 不 一 样 的 是 ， 网 络 层 是 通过 硬件 实现 负载 均衡 ， 而 中 间 件 层 是 通过 软件 实现 的 。 同时， 其 


按照 一 定 的 逻辑 配置 连接 数据 源 。 
. 数据 路 由 : 隶属 于 中 间 件 层 ， 是 数据 库 层 的 一 个 前 栈 ， 实 现 分 布 式 数据 存储 的 路 由 。 一 般 来 说 ， 若 数据 库 使 用 分 布 式 存储 ， 则 这 个 组 件 都 是 不 可 少 的 。 


“ 数据 库 层 : 这 是 我 们 最 关心 的 ， 也 是 最 底层 的 结构 ， 可 分 为 核心 数据 库 层 和 前 置 数据 库 层 。 
核心 数据 库 层 : 传统 意义 上 的 数据 库 群 所 在 的 区 域 ， 我 们 按照 不 同 的 功能 应 用 ， 区 分 不 同 的 数据 库存 储 ， 包 括 核心 库 、 子 系统 库 、 灾 备 库 〈 可 细 分 为 远程 灾 备 和 本 地 灾 备 ) 。 如 果 业 务 扩展 ， 则 可 


以 通过 ADG 库 和 T-1 交 易 库 实现 部 分 业务 的 分 离 ， 这 两 个 概念 我 们 会 在 “纵横 篇 ”详细 介绍 
前 置 数据 库 层 : 这 个 层级 可 以 部 署 在 核心 数据 库 层 的 前 端 ， 也 可 以 平行 部 署 。 其 另 一 种 叫 法 是 “数据 库 中 间 层 ”。 可 以 部 署 一 些 内 存 数 据 库 ， 分 离 高 并 发 业务 到 这 个 区 域 ， 也 可 以 部 署 一 些 开源 的 


分 离 边缘 化 的 应 用 于 其 中 。 
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图 1-4 系统 架构 概要 
层 来 说 吧 ， 我 们 平滑 地 实现 数据 存储 的 横向 和 纵向 的 扩展 ， 并 对 上 一 


可 以 看 到 ， 一 个 完整 的 架构 远 比 我 们 想象 得 要 复杂 ， 云 的 概念 也 是 基于 这 个 架构 逐渐 衍生 出 来 的 。 就 拿 数据 库 
我 们 就 实现 了 数据 库 的 池 化 ， 也 就 是 说 对 外 服务 的 数据 库 可 以 视 为 一 个 ， 基 本 上 实现 了 数据 库 云 架构 。 

从 以 上 架构 来 看 ， 高 并 发 的 压力 经 过 了 网 络 层 和 中 间 件 层 的 过 滤 ， 到 达 最 底层 的 数据 库 层 ， 基 本 上 都 不 会 有 压力 了 ， 应 用 层 、 网 络 层 、 中 间 件 层 都 可 以 视 为 数据 库 的 保护 层 。 当 我 们 进行 应 用 系统 压力 
测试 的 时 候 ， 绝 大 多 数 情况 下 ， 数 据 库 都 是 没有 太 大 压力 的 ， 最 容易 出 现 问题 的 往往 是 中 间 件 层 ， 换 而 言 之 ， 在 数据 库 被 压 垮 之 前 中 间 件 层 已 经 被 压 垮 了 。 这 也 提醒 我 们 只 做 系统 应 用 压力 测试 是 不 够 的 ， 


我 们 还 需要 做 数据 库 的 压力 测试 ， 找 到 数据 库 层 的 瓶颈 所 在 。 


这 样 是 不 是 可 以 就 此 高 枕 无 忧 了 呢 ?” 当 然 不 能 ,数据 库 出 现 高 并 发 压力 在 实际 应 用 中 还 是 比较 常见 的 。 难 道 我 们 前 面 说 的 不 对 ? 不 是 的 ， 可 以 看 到 不 论 是 网 络 层 ， 还 是 中 间 件 层 ， 都 是 在 分 流 压力 ， 压 
力 并 没有 赁 空 消失 ， 这 些 用 户 会 话 要 访问 的 数据 分 布 是 无 法 控制 的 ， 如 果 分 布 过 于 集中 ， 那 么 数据 库 会 在 某 一 个 点 上 出 现 高 并 发 争 用 ， 也 就 是 热点 争 用 ， 如 上 述 谈话 的 背景 一 样 。 


面 对 高 并 发 压力 ， 我 们 现在 已 经 很 清楚 自己 要 做 什么 了 吧 ? 就 是 一 定 程度 上 实现 数据 访问 的 分 流 工作 ， 也 就 是 通常 所 说 的 纵横 扩展 。 另 一 方面 来 看 ， 任 何 的 扩展 都 是 有 一 个 核心 点 的 ， 就 是 我 们 的 
Oracle 数 据 库 ， 扩 展 工作 在 一 定 程度 上 是 对 其 核心 地 位 的 弱化 ， 但 是 核心 仍然 是 核心 ， 在 扩展 之 前 ， 必 须 做 好 Oracle 核 心 库 的 设计 。 


1.2 ”说 句 时 艇 话 


活 在 当下 ， 对 于 IT 人 来 说 ， 是 再 合适 不 过 的 说 法 了 。IT 行 业 的 发 展 速 度 堪 比 高 铁 、 火 箭 ， 每 一 个 IT 人 都 在 担心 自己 的 知识 领域 明天 就 要 过 时 ， 不 得 不 每 天 学 习 新 的 知识 ， 无 奈 的 是 跑 得 再 快 也 没有 办 法 追 
得 上 火箭 。 


在 数据 库 的 领域 里 ， 也 是 时 刻 都 在 出 现 新 概念 和 新 产品 。 创 新 ， 成 了 每 个 人 、 每 个 企业 都 在 不 断 追逐 的 东西 。 现 有 的 东西 ， 做 好 了 是 应 该 的 ， 做 不 好 要 接受 惩罚 ; 创新 的 东西 ， 做 不 好 是 应 该 的 ， 做 好 
就 是 绩效 。 当 创新 和 KPI 绩效 直接 联系 到 一 起 的 时 候 ， 大 家 都 不 再 是 为 了 创新 而 去 创新 ， 而 是 为 了 KPI 而 去 创新 ， 甚 至 出 现 了 微 创新 的 说 法 ， 可 以 是 一 种 方法 的 引进 ， 或 者 一 种 新 数据 库 的 引进 。 然 而 ， 创 新 
这 东西 是 由 需求 来 驱动 的 ， 人 家 的 需求 未 必 是 我 们 的 需求 。 人 家 的 创新 就 像 人 家 的 衣服 ， 人 家 穿 得 很 漂亮 ， 我 们 拿 来 穿 可 能 就 很 别扭 了 。 


每 个 行业 都 有 一 到 两 个 领军 的 企业 ， 他 们 在 做 什么 ， 同 行业 的 人 就 跟着 做 什么 ， 我 也 是 经 常 被 同行 们 问 起 最 近 在 做 什么 ， 如 何 做 的 。 同 行业 的 借鉴 和 学 习 当然 是 好 事 ， 但 也 要 考虑 到 自身 的 现实 条 件 ， 
不 要 在 数据 库 总 容量 只 有 几 个 TB 的 时 候 ， 就 非 要 去 搞 什么 大 数据 。 


由 于 市 场 利益 的 驱动 ， 很 多 企业 也 开始 跨行 业 发 展 。 为 了 能 够 快速 地 融入 并 占领 不 熟悉 的 行业 领域 ， 不 惜 生 搬 硬 套 该 行业 已 成 型 的 东西 ， 由 于 急功近利 而 缺乏 沉淀 ， 直 接 导 致 东 施 效 客 的 结果 。 更 有 甚 
者 ， 不 分 良 其， 言 必 称 希腊 。 


1.2.1 谈 谈 去 IOE 


去 IOE， 具 体 不 知道 从 什么 时 候 开 始 ， 在 数据 库 领域 里 掀起 了 一 波 不 算 大 也 不 算 小 的 浪潮 。 是 赞 是 贬 ， 是 喜 是 忧 ， 一 半 一 半 。 


: 去 I: 就 是 废弃 以 JBM 为 代表 的 高 价 小 型 机 ; 


' 去 DO: 就 是 废弃 以 Oracle 为 代表 的 集中 式 数据 库 ; 


“ 去 已 : 就 是 废弃 以 EMC 为 代表 的 高 端 存储 设备 。 


废弃 这 些 高 端 大 气 上 档次 的 东西 ， 取 而 代 之 的 是 使 用 开源 的 软件 。 暂 且 不 说 开源 软件 的 优 缺 点 吧 ， 先 来 看 看 为 什么 要 去 IOE 呢 ?不 说 始作俑者 是 何 用 意 ， 后 来 者 更 多 的 是 一 种 盲从 跟风 的 心态 ， 正 如 前 
面 所 说 的 一 样 。 下 面 我 们 从 两 个 维度 来 分 析 一 下 看 看 吧 : 


1 以 公司 为 中 心 


去 掉 了 IOFE 确 实 能 给 公司 节省 下 不 少 的 硬件 成 本 ， 但 如 果 你 就 此 简单 地 认为 IT 成 本 降低 了 ， 那 就 错 了 。 这 部 分 节省 的 硬件 成 本 将 转化 成 软件 成 本 附加 到 IT 开发 和 运 维 上 面 。 这 些 软件 成 本 将 包括 以 下 几 个 
方面 。 


“ 开发 运 维 人 员 再 学 习 和 再 培训 的 成 本 ， 如 果 公司 不 打算 把 原 班 人 马 全 部 开 樟 。 


“ 数据 库 开 发 运 维 的 成 本 将 增加 ， 且 不 可 控 。 开 源 数据 库 的 开发 运 维和 Oracle 数 据 库 的 开发 运 维 是 完全 不 同 的 ，Oracle 数 据 库 有 强大 的 优化 机 制 ， 让 一 些 不 算 太 好 的 SQL 也 能 表现 得 不 错 。 开 源 数 据 库 则 
不 然 ， 需 要 更 多 人 力 投 入 到 优化 开发 和 设计 中 。 不 幸 的 是 ， 这 就 像 一 个 无 底 洞 ， 谁 也 不 能 预 估 将 需要 多 少 人 力 成 本 的 投入 。 


: 开发 运 维 风险 增 加 ， 且 不 可 控 。 使 用 开源 的 东西 ， 意 味 着 失去 专业 厂商 的 支持 ， 什 么 问题 都 要 靠 自 己 解 决 ， 万 一 解决 不 了 就 只 能 等 死 。 


面临 成 本 和 风险 的 不 可 控 ， 需 要 稳步 发 展 的 企业 是 否 还 值得 选择 去 IOE 呢 ? 如 果 说 出 于 战略 考虑 ， 可 以 不 用 受制 于 IOE， 那 么 就 算 去 掉 了 ， 不 是 还 要 受制 于 PC Server 吗 ? 同时， 系统 的 开发 运 维 更 加 依 
赖 于 技术 人 员 ， 不 是 更 加 受制 于 技术 人 员 吗 ? 


2. 以 技术 为 中 心 


以 技术 为 中 心 ， 也 就 是 以 技术 人 为 中 心 。 我 记得 我 曾经 在 一 次 |OE 的 话题 讨论 中 问 过 一 个 问题 : “ 谁 愿意 在 情人 节 跟 女友 出 去 约会 的 时 候 ， 突 然 被 叫 回 来 处 理 故障 呢 ” 谁 愿意 在 陪 孩子 亲子 活动 的 时 
候 ， 突 然 被 叫 回来 处 理 故 障 呢 ?“ 


如 果 去 了 IOE， 就 失去 了 专业 的 服务 支持 ， 这 些 都 将 变 成 可 能 。 当 然 ， 热 囊 于 以 公司 为 家 的 技术 人 不 在 讨论 范围 内 。 


客观 地 来 说 ， 每 一 种 技术 、 每 一 种 产品 都 有 其 作用 的 领域 ， 没 有 万 能 的 数据 库 ， 也 没有 万 能 的 架构 ， 只 有 万 变 的 需求 和 随机 应 变 的 设计 。1IOE 有 其 广阔 的 作用 域 ， 也 有 其 不 擅长 之 处 ， 成 熟 的 设计 应 该 
是 用 其 所 长 ， 避 其 所 短 ， 不 走 极端 路 线 。 


1.2.2 ”开源 的 作用 域 


开源 数据 库 软件 横 空 出 世 ， 一 下 子 占领 了 众多 使 用 领域 。 开 句 玩笑 地 说 ， 不 会 一 两 个 开源 数据 库 都 不 好 意思 说 自己 是 搞 数据 库 的 。 是 的 ， 开 源 数 据 库 就 这 么 应 时 应 景 地 来 了 。 


我 们 前 面 说 了 ， 每 一 种 产品 和 技术 都 是 有 其 作用 域 的 ， 开 源 数 据 库 更 是 如 此 ， 可 以 说 某 一 种 开源 数据 库 就 是 为 了 某 一 种 应 用 场景 而 研发 的 。 比 如 ，MongoDB 是 一 种 基于 分 布 式 文档 存储 的 非 关 系 型 数 
据 库 ， 其 优势 在 于 查询 功能 比较 强大 ， 提 供 可 扩展 的 高 性 能 数据 存储 ， 可 用 于 地 图 路 点 信息 的 存储 。Redis 作 为 一 种 开源 内 存 数据 库 ， 数 据 保 存在 内 存 中 ， 通 过 网 络 直接 存 取 ， 优 势 是 速度 快 ， 高 并 发 处 理 能 
力 强 。 


那 如 何 定位 开源 数据 库 的 使 用 领域 呢 ? 立足 于 传统 行业 ， 我 还 是 持 有 一 种 比较 保守 的 观点 : 


“ 非 核心 的 外 围 业 务 应 用 ; 


“ 最 好 是 作为 核心 Oracle 数据 库 的 扩展 ， 不 必 独 立 进行 业务 支持 。 


然而 ， 如 果 立 足 点 是 类 似 互联 网 这 些 比较 前 卫 激进 的 行业 ， 那 么 万 物 皆 可 开源 。 


1.3 ”在 Oracle 的 世界 里 


E 骨 也 是 以 此 为 出 发 点 ， 立 足 Oracle 的 世界 ， 以 海纳百川 的 胸怀 选择 性 吸收 各 种 数据 库 的 使 用 。 


如 果 你 是 一 位 Oracle 数 据 库 的 使 用 者 ， 那 么 我 们 说 你 将 是 立足 在 Oracle 的 世界 里 的 。 本 书 的 3 


立足 点 的 不 同 ， 同 样 会 影响 到 我 们 视角 不 同 ， 那 么 在 Oracle 的 世界 里 的 高 并 发 数据 库 系统 架构 设计 将 会 是 怎么 样 的 呢 ? 这 也 将 是 本 书 需要 给 读者 们 介绍 的 。 
“将 技术 的 东西 当成 一 种 艺术 去 做 ， 那 你 将 不 再 是 简 


相信 在 每 一 个 Oracle 数 据 库 用 户 的 眼中 都 有 其 独特 的 风景 ， 对 Oracle 的 理解 可 以 是 技术 的 ， 更 可 以 是 艺术 的 。 在 讨论 中 ， 我 经 常 提 及 的 一 个 观点 : 
单 的 技术 者 ， 而 是 更 富 创造 力 的 艺术 家 。 


1.3.1 数据库 森林 体系 


在 这 里 ， 我 们 也 不 妨 东 施 效 筝 一 回 ， 模 仿 经 济 学 里 的 “ 布 林 顿 森林 体系 ”， 架 构 一 个 属于 数据 库 领 域 的 “数据 库 森 林 体 系 ”。 
数据 库 森 林 体系 ， 是 指 以 Oracle 数 据 库 为 核心 的 多 种 数据 库 集群 工作 的 生态 体系 。 该 体系 的 特点 应 该 是 : 

“ 应 用 系统 核心 内 容 和 性 能 直接 与 Oracle 数 据 库 挂钩 ; 

“ 其 他 类 别 和 功能 的 数据 库 与 Oracle 核心 库 挂 钩 ; 


“ 其 他 类 别 和 功能 的 数据 库 与 Oracle 数 据 库 按 业务 需求 实现 数据 同步 与 交互 


“ 其 他 类 别 和 功能 的 数据 库 作为 Oracle 核 心 库 的 扩展 ， 分 摊 前 端 或 外 围 业务 支持 。 


两 个 维度 展开 纵横 方向 的 扩展 。 


回 


司 1-5 所 示 为 一 套 比较 完备 的 数据 库 森 林 体系 架构 图 。 秉 承 以 Oracle 核 心 库 为 中 心 ， 从 业务 逻辑 层面 、 数 据 库 功能 层 


开源 


数据 库 


| - 
| 子 系统 库 


We 


子 系统 库 
We 


T-1 交 易 库 


图 1-5 数据库 森 林 体 系 图 


Oracle 核 心 库 与 Oracle 子 系统 库 、MySQL 子 系统 库 之 间 ， 使 用 GoldenGate 实 现 即 时 的 数据 同步 ，MySQL 子 系统 库 是 单 向 同步 ， 它 的 角色 更 像 是 一 只 伸 出 去 的 手 ， 处 理 前 置业 务 。 


Oracle 核 心 库 与 灾 备 库 之 间 通 过 Data Guard 功 能 实现 异步 同步 ， 起 到 灾难 备份 的 作用 ， 特 殊 情 况 下 ， 也 是 可 以 临时 打开 使 用 的 。 
服务 于 只 读 业 务 ; T-1 交 易 库 则 可 视 为 过 期 的 核心 库 映像 ， 可 以 给 时 效 要 求 


同样 ， 在 核心 库 与 ADG 库 、T-1 交 易 库 之 间 也 是 通过 Data Guard 功 能 实现 数据 同步 。ADG 库 可 以 看 成 是 核心 库 即时 的 映像 ， 
不 高 的 业务 提供 读 写 服务 。 如 果 必 要 的 话 ， 通 过 ADG 库 衍生 出 一 些 开源 数据 库 的 业务 应 用 ， 就 像 伸 出 去 的 男 一 只 手 ， 处 理 前 置业 务 。 


对 于 前 面 提 到 的 Oracle 核 心 库 的 高 并 发 热点 争 用 问题 ， 可 以 将 这 部 分 业务 分 离 到 前 置 的 TimesTen 内 存 数 据 库 中 ， 提 高 高 并 发 会 话 的 响应 速度 ， 其 可 通过 TimesTen 提 供 的 方法 和 接口 实现 与 Oracle 核 心 


库 的 即时 数据 同步 。 
当然 ， 数 据 库 森 林 体 系 也 可 以 视 为 一 种 高 并 发 热点 争 用 问题 的 解决 方法 论 ， 不 要 求全 盘 实 现 ， 可 以 选择 性 地 搭建 ， 满 足 了 需求 就 是 最 佳 的 架构 设计 。 


说 到 高 并 发 处 理 能 力 的 提升 ， 就 会 不 只 一 次 地 被 问 及 Oracle 数 据 库 的 RAC 架 构 。 我 只 能 说 RAC 只 是 一 种 高 可 用 的 解决 方案 ， 对 于 高 并 发 问题 ， 它 未 必 擅 长 。 高 并 发 热点 问题 ， 往 往 成 了 它 的 短 板 ，RAC 
环境 甚至 会 加 剧 问题 的 影响 程度 。 举 个 例子 来 说 ， 我 们 将 会 在 高 效 索 引 设计 章节 提 到 的 高 并 发 会 话 导致 主键 索引 分 裂 的 等 待 事件 一 “enq: TX-index contention”， 如 果 这 个 问题 不 先 解决 掉 ， 从 单 节 点 


到 RAC 的 迁移 后 ， 问 题 将 更 加 显著 。 


， 集 高 可 用 、 高 可 靠 、 高 并 发 、 高 性 能 的 光环 于 一 身 。RAC 一 度 风行 的 时 人 息 ， 技 术 人 员 如 果 不 会 RAC 都 不 好 意思 说 


从 历史 来 看 ， 国 人 好 像 都 很 喜好 RAC 数 据 库 架构 ， 并 无 形 中 夸大 了 RAC 数 据 库 的 作 
自己 是 Oracle 数 据 库 的 DBA， 公 司 如 果 没有 RAC 数 据 库 都 不 好 意思 说 自己 的 业务 量 大 。 这 和 前 面 提 到 的 盲目 夸大 去 1OE 的 现象 是 一 样 的 ， 光 环 效应 是 要 不 得 的 。 


然而 ，RAC 确 实 也 是 一 个 不 错 的 东西 ， 如 果 在 节点 应 用 之 间 尽 可 能 地 实现 了 业务 的 独立 ， 也 就 是 说 按 节 点 完全 区 分 业务 应 用 ， 其 处 理 并 发 的 能 力 是 有 一 定 的 优势 的 ， 但 是 是 在 解决 了 数据 库 结构 分 散 的 
前 提 下 。 
为 什么 这 么 说 呢 ? 我 们 知道 不 论 是 RAC 数 据 库 还 是 单 节点 数据 库 ， 物 理 存 在 的 数据 库 只 有 一 套 ， 如 果 数 据 库 内 部 实现 了 业务 逻辑 上 的 必要 隔离 ， 各 节点 就 能 各 行 其 道 ， 反 之 ， 各 节点 的 争 用 会 更 加 剧 


烈 。 与 其 纠结 在 这 个 问题 上 ， 不 如 跳出 来 看 问题 ， 为 什么 不 干脆 将 其 按 业务 逻辑 拆 成 多 个 库 呢 ?” 必 要 的 共享 数据 ， 可 以 通过 即时 同步 来 实现 。 


如 图 1-6 所 示 ， 在 左边 RAC 架 构 中 ,实例 1 对 应 业务 1， 有 其 独 有 的 数据 部 分 ， 实 例 2 对 应 业务 2， 也 有 其 独 有 的 数据 部 分 ， 两 种 业务 有 一 定 的 关联 性 ， 所 以 还 存在 共享 数据 部 分 。 演 变 成 右边 的 架构 ， 将 


同步 ， 业 务 并 发 处 理 能 力也 提高 了 。 回 过 头 再 来 看 一 下 我 们 的 数据 库 森 林 体 系 ， 核 心 库 、 子 系统 库 以 及 各 种 功能 库 ， 不 就 是 数据 库 按 业务 逻辑 拆 分 的 结果 吗 ? 


EL 


图 1-6 RAC 架构 拆 分 


近年 来 ， 大 家 也 能 更 加 理性 地 看 待 RAC 数 据 库 架 构 了 ， 与 其 面 对 额外 的 采购 成 本 和 运 维 成 本 ， 不 如 干脆 拆 开 来 ， 用 简单 的 架构 来 取而代之 ， 这 也 正 是 大 道 至 简 的 精神 。 


我 们 说 高 并 发 处 理 未 必 是 RAC 的 强项 ， 但 高 可 用 就 一 定 是 了 。 当 一 套数 据 库 应 用 系统 提出 如 下 需求 的 时 候 ， 我 们 将 终 庸 置疑 地 给 出 RAC 的 解决 方案 : 


“ 业务 7X24 小 时 在 线 ; 


“ 尽 可 能 短 的 故障 停机 修复 时 间 ，10 分 钟 以 内 、5 分 钟 以 内 ， 其 至 更 短 。 


1.3.2 ”大道 至 简 


其 拆 分 成 两 个 独立 的 单 节点 数据 库 ， 其 中 数据 共享 时 效 要 求 较 低 的 进行 数据 库 间 即时 同步 ， 时 效 要 求 很 高 的 元 余 到 各 自 业 务 数据 库 中 。 这 样 做 虽然 数据 库 的 总 容量 大 了 ， 但 是 架构 简单 了 ， 少 了 内 存 的 即时 


在 此 我 们 不 得 不 先 提 到 一 个 概念 ， 就 是 数据 库 架 构 师 的 “ 术 ” 与 “ 道 ”。 业 内 很 多 数据 库 架 构 师 往往 是 技术 水 平 比较 高 的 DBA 的 升级 版 ， 这 是 一 个 比较 典型 的 以 “ 术 ” 为 导向 的 结果 ， 一 切 以 技术 说 
话 ， 这 往往 造就 了 架构 的 局 限 性 ， 甚 至 凡事 唯 技 术 论 。 好 比 很 多 项 目 在 制定 目标 的 时 候 ,会 把 某 项 新 技术 的 实现 作为 目标 之 一 ， 造 成 驴 层 不 对 马 嘴 的 后 果 。 一 个 成 功 的 数据 库 架 构 师 应 该 是 以 “ 道 ”为 导 


向 ， 那 何 为 数据 库 架构 师 的 “ 道 ” 呢 ? 在 这 里 我 先 卖 一 个 关子 ， 将 在 本 书 的 第 9 章 中 展开 讨论 。 


我 曾经 在 一 次 技术 沙龙 上 跟 几 位 朋友 讨论 过 一 个 话题 : 如 何 看 待 数据 库 五 花 八 门 的 新 特性 呢 ? 当 说 起 需求 是 高 并 发 处 理 的 数据 库 的 时 候 ， 大 家 达成 一 种 共识 ， 就 是 架构 需要 设计 得 充分 简单 ， 简 和 
能 灵活 地 扩展 ， 对 于 一 些 不 熟悉 或 者 没有 实战 经 验 的 新 特性 ， 可 以 不 用 就 不 


有 了 才 


然而 ， 设 计 简单 的 架构 并 不 意味 着 架构 简单 的 设计 ， 越 是 简单 的 东西 越 是 考验 设计 者 的 思想 ， 需 要 对 简单 的 东西 充分 细 化 。 立 足 在 Oracle 的 世界 里 ， 有 哪些 是 至 简 而 至 要 的 东西 呢 》 就 是 数据 库 森 林 体 


系 中 蕴藏 的 设计 的 大 道 。 


数据 库 森 林 体系 看 似 复杂 的 架构 背后 ， 至 简 的 大 道 无 外 乎 就 是 对 表 、 索 引 、 优 化 器 设计 的 把 握 ， 以 及 以 核心 库 为 中 心 的 功能 数据 库 与 前 置 数据 库 的 纵横 扩展 。 本 书 将 分 作 两 个 部 分 ， 对 这 两 项 内 容 具 体 


展开 阅 述 ， 其 目的 不 在 于 帮助 读者 解决 某 个 具体 的 高 并 发 问题 ， 而 是 则 在 分 享 一 种 方法 论 ， 开 辟 一 种 思路 。 或 许 你 在 阅读 的 时 候 能 够 得 到 一 点 启发 ， 演 化 出 更 高 明 的 观点 ， 那 么 我 写作 本 书 的 目的 也 就 达到 
了 ， 也 正 是 我 的 大 道 。 


14 本 章 小 结 


纵 观 本 章 ， 主 要 介绍 了 一 下 高 并 发 Oracle 数 据 库 系统 的 特点 、 难 点 以 及 架构 和 设计 的 基本 思路 ， 并 闲话 了 一 些 时 下 流行 的 话题 。 下 一 章 我 们 将 进入 本 书 的 正题 ， 给 读者 们 介绍 如 何在 Oracle 数 据 库 里 进 


行 高 效 索 引 的 设计 。 


第 2 章 ”高 效 B 树 索引 


“ 索引 扫描 识别 ， 介 绍 索引 的 基本 概念 及 展开 讨论 各 种 索引 的 扫描 方式 。 
:索引 与 排序 ， 介 绍 索引 在 排序 过 程 中 的 作用 和 意义 。 
: 索引 设计 优化 ， 深 入 解析 索引 设计 的 方法 技巧 ， 以 及 设计 索引 的 影响 因素 。 


“ 索引 分 裂 ， 深 入 剖析 索引 树 分 裂 生 长 原理 及 因此 带 来 的 问题 和 解决 方法 。 


“ 索引 维护 ， 围 绕 索 引 重 建 探讨 索引 后 期 维护 的 方法 。 


众所周知 ， 索 引 不 论 在 数据 库 设 计 过 程 中 ， 还 是 在 应 用 程序 开发 过 程 中 都 是 一 个 至 关 重 要 的 方面 。 索 引 的 使 用 正确 与 否 直接 影响 到 应 用 程序 的 性 能 ， 并 且 它 是 贯穿 于 设计 、 开 发 、 运 维 的 各 个 阶段 的 。 


我 们 为 什么 要 使 用 索引 呢 ? 简单 地 说 ， 数 据 库 建 立 索引 是 为 了 获取 更 好 的 数据 读 取 性 能 ， 同 时 ， 牺 牲 掉 一 部 分 的 数据 写 入 性 能 。 索 引 是 一 把 双 丸 剑 ， 对 于 一 张 数据 表 来 说 ， 如 果 索 引 数 量 太 多 ， 应 用 程 
序 的 写 入 性 能 可 能 会 受到 影响 ， 如 果 索 引 太 少 ， 又 起 不 到 优化 查询 性 能 的 作用 。 如 果 你 的 系统 是 一 套 并 发 度 很 高 的 OLTP 系 统 ， 那 么 这 种 影响 将 被 加 剧 。 找 到 一 个 平衡 点 将 是 一 套 应 用 程序 设计 成 功 与 否 的 关 
键 所 在 。 


本 章 的 主旨 是 为 大 家 揭 开 索引 神秘 的 面纱 ， 从 索引 的 扫描 、 排 序 、 分 裂 、 维 护 、 优 化 5 个 角度 ， 深 入 剖析 索引 设计 和 维护 过 程 中 的 方法 和 技巧 。 


2.1 索引 扫描 识别 


如 果 把 我 们 的 数据 库 比 喻 成 一 座 图 书馆 ， 那 表 作 为 数据 的 载体 ， 则 是 一 本 一 本 的 图 书 ， 而 索引 则 是 图 书 的 目录 。 目 录 不 仅 让 图 书 阅读 和 查找 变 得 方便 ， 更 是 图 书 成 败 的 关键 。 


也 许 有 人 会 说 ， 我 翻阅 的 是 一 本 杂志 ， 内 容 本 就 不 多 ， 我 甚至 不 需要 目录 。 是 的 ，Oracle 数 据 库 也 考虑 到 了 这 一 点 ， 对 于 数据 量 很 小 的 表 ， 我 们 可 以 不 建 索 引 ， 在 查询 时 可 以 进行 全 表 扫 描 (FULL 
TABLE SCAN) ， 这 种 方式 对 于 小 表 来 说 更 适合 。 但 是 ， 如 果 我 们 手 上 是 一 本 大 字典 呢 ? 你 甚至 一 个 人 都 搬 不 动 它 ， 当 然 你 也 不 必 像 看 杂志 一 样 每 页 都 去 翻阅 ， 只 需要 查询 到 真正 需要 的 内 容 即 可 。 这 个 时 
候 我 们 就 需要 目录 了 ， 甚 至 是 多 样 类 别 的 目录 ， 比 如 : 拼音 目录 、 部 首 目录 等 ， 这 样 我 们 可 以 根据 不 同 的 需求 选择 不 同 的 目录 。 同 样 ，Oracle 数 据 库 也 为 不 同 的 查询 者 提供 了 不 同类 别 的 索引 ， 最 常用 的 也 
是 默认 的 索引 就 是 接 下 来 要 说 的 B 树 索引 。 


B 树 索引 的 扫描 就 像 目录 的 翻阅， 高 效 的 扫描 方式 才能 带 来 快速 的 信息 获取 ， 本 节 将 给 读者 介绍 B 树 索引 的 几 种 常见 扫描 方式 。 


2.1.1 B 树 索引 


在 正式 开始 之 前 ， 我 们 先 来 介绍 一 下 什么 是 B 树 索引 。 顾 名 思 义 ，B 树 索引 是 一 种 树 形 结构 的 数据 库 对 象 ， 它 由 根 节点 、 分 支 节点 、 叶 节点 三 部 分 组 成 。 如 图 2-1 所 示 ， 根 节点 存储 着 指向 分 支 节点 的 指 
针 ， 分 支 节点 则 存储 着 指向 叶 节点 的 指针 ， 索 引 的 条 目 最 终 是 存储 在 各 个 叶 节点 上 的 。 根 节点 和 分 支 节点 一 方面 是 作为 索引 条 目 快 捷 的 数据 路 由 ， 另 一 方面 也 是 通过 算法 将 索引 条 目 分 布 均匀 。 


根 节 点 


- 


节点 加 


国 国 索引 条 日 头 
xs IT  。 国 ae 
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我 们 说 过 索引 就 像 表 的 目录 ， 那 目录 条 目 会 有 哪些 内 容 呢 ， 其 中 我 们 最 关心 的 是 什么 呢 ? 毋庸 置疑 ， 我 们 最 关心 的 必 是 对 应 章节 的 开始 页 码 。 在 B 树 索引 的 叶 节 点 索引 条 目 中 也 包含 了 这 个 页 码 
ROWID， 它 指明 了 对 应 数据 实际 存储 的 物理 位 置 ， 也 是 我 们 进行 索引 扫描 的 目的 。 


图 2-1 B 树 索引 


2.1.2 “全 表 扫描 


说 到 索引 扫描 ， 不 得 不 提 的 就 是 全 表 扫 描 (FULL TABLE SCAN) 了 ， 因 为 在 一 定 程度 上 ， 引 进 索 引 扫 描 就 是 为 了 取代 全 表 扫 描 。 


全 表 扫 描 (FULL TABLE SCAN) 就 是 在 数据 查询 过 程 中 ， 对 整 张 表 的 全 部 低 于 高 水 位 标记 (High Water Mark，HWM) 的 数据 块 (Data Block) 进行 读 取 。 如 图 2-2 所 示 ， 可 以 说 单 次 查询 需要 读 取 
全 表 的 数据 ， 对 于 小 表 来 说， 这 是 无 可 厚 非 的 ， 甚 至 可 能 是 最 优 的 方式 。 但 如 果 是 一 张 数据 量 较 大 的 表 ， 这 将 导致 很 多 非 必要 的 数据 块 读 取 ， 造 成 过 多 的 MO 开销 。 


:HWM 


图 2-2 全 表 扫 描 


从 另 一 方面 来 讲 ， 判 断 一 次 索引 扫描 是 否 高 效 的 标准 就 是 将 其 与 全 表 扫 描 进 行 比较 ， 如 果 较 之 成 本 更 低 ， 那 么 索引 扫描 可 以 被 视 为 高 效 的 ， 反 之 则 是 需要 优化 的 。 


通过 一 个 例子 来 简单 对 比 一 下 吧 。 从 返回 结果 来 看 ， 表 alex_t00 有 10 万 行 记录 ， 不 算 一 个 小 表 了 ， 执 行 计划 的 成 本 开销 (COST) 中 ， 全 表 扫描 COST = 84， 而 索引 扫描 COST = 44， 全 表 扫 描 的 执行 效 
率 是 非常 低 的 。 两 种 扫描 的 效率 对 比如 下 所 示 : 


SQL> select /*+full (alex t00)*/ count (*) from alex t00; 
COUNT (*) 


0 | SELECT STATEMENT | 工 | 84 (2)1 00:00:02 | 
| 1 | SORT AGGREGATE | | 1 | | | 
2 | TABLE ACCESS FULL| ALEX T00 | 100K| 84 (2)1 00:00:02 | 
SQL> select count (*) from alex t00; 
COUNT (*) 


| 0 | SELECT STATEMENT | | 1 | 44 (3)1 00:00:01 | 
| 1 | SORT AGGREGATE | | | 
| 5 INDEX FAST FULL SCAN| PK ALEX T00 | 100K| 44 (3)1 00:00:01 | 


@ia 全 表 扫 描 ， 对 于 小 表 来 说 是 最 优选 择 ， 对 于 没有 合适 的 索引 的 大 表 来 说 ， 也 是 不 错 的 选择 。 


2.1.3 ROWID 扫 描 


我 们 已 经 了 解 到 ROWID 其 实 就 是 索引 的 “页 码 ”， 它 是 Oracle 提 供 的 伪 列 ， 一 般 说 来 每 一 行 数据 都 对 应 一 个 固定 且 唯 一 的 ROWID， 在 这 一 行 数据 存 入 数据 库 的 时 候 就 确定 了 。ROWID 扫 描 查 询 示 例如 
下 所 示 : 


SQL> select rowid from alex t00 where jid=17 
ROWID 


AAA3YkKAAEAAAAVIAAA 
SQL> explain plan for select * from alex t00 
2 where rowid="'AAA3YkAAFEAAAAVIAAA'; 


| 
| 1 | TABLE ACCESS BY USER ROWID| ALEX T00 | 1 1 32 1 1 | 


从 上 面 这 个 查询 例子 可 以 看 到 ，ROWID 是 基于 64 位 编码 的 18 个 字符 显示 ， 它 记录 了 数据 对 象 的 编号 、 文 件 编号 、 块 编号 、 行 编号 ， 即 数据 行 存储 的 物理 位 置 ， 如 表 2-1 所 示 : 


表 2-1 ROWID 组 成 


数据 对 象 编号 文件 编号 块 编号 行 编号 
AAA3YK AAE AAAAV] AAA 


利用 ROWID 来 查询 记录 ， 其 实 就 是 根据 数据 行 实际 存储 的 位 置 来 获取 数据 。 通 过 ROWID 查 询 记录 是 查询 速度 最 快 的 查询 方法 ， 比 任何 索引 扫描 方式 都 要 快速 。 为 什么 这 么 说 呢 ? 我们 说 索引 扫描 实质 
上 可 以 分 解 成 两 个 动作 : 


“ 索引 结构 扫描 ， 获 取 待 返回 数据 行 的 ROWID; 


“ 根据 获取 的 ROWID 扫 描 表 ， 获 取 对 应 数据 行 ， 并 返回 。 


本 


ROWID 的 扫描 方式 其 实 就 是 索引 扫描 的 第 二 个 动作 ， 换 而 言 之 ， 索 引 扫 描 的 目标 就 是 通过 ROWID 扫 描 的 方式 从 表 中 获取 查询 数据 行 。 


通过 dbms_rowid 这 个 包 ， 可 以 直接 得 到 具体 的 ROWID 所 包含 的 信息 : 


SQL> select dbms rowid.rowid object (rowid) object id 
2 ms rowid.rowid relative fnol(rowid) file id 
3 dbms_ rowid.rowid block number (rowid) block id, 
4 dbms rowid.rowid row number (rowid) num 
5 from alex t00 0 
6 where id= 1; 


OBJECT ID FILE ID BLOCK _ID NUM 


226852 4 3045 0 


Oi ROWID 扫 描 方 式 是 查询 取 数 最 快 的 方式 ， 索 引 检索 的 本 质 也 是 转换 为 ROWID 扫 描 取 数 。 


2.1.4 ”索引 唯一 扫描 


从 上 面 的 介绍 ， 我 们 可 以 了 解 到 索引 扫描 的 过 程 其 实 是 扫描 索引 结构 获取 ROWID 的 过 程 。 索 引 唯 一 扫描 (INDEX UNIQUE SCAN) 只 能 发 生 在 唯一 键 索引 (主键 索引 实质 即 为 唯一 键 索引 ) 上 ， 通 过 
唯一 索引 查找 数值 往往 返回 单个 OWID， 如 图 2-3 所 示 ， 从 索引 的 根 (root) 节点 到 枝 (branch) 节点 ， 再 到 叶 (leaf) 节点 上 存储 着 一 个 对 应 的 ROWID， 即 对 应 的 查询 结果 也 只 返回 一 行 ， 这 种 存 取 方 法 
称 为 “索引 唯一 扫描 ”。 如 果 该 唯一 索引 是 由 多 个 列 组 成 的 组 合 索引 ， 则 至 少 要 有 组 合 索引 的 前 导 列 参与 到 该 查询 中 ， 同 样 SQL 语句 只 返回 一 行 记录 ， 这 也 属于 索引 唯一 扫描 。 


branch 


7 


图 2-3 索引 唯一 扫描 
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下 面 通过 一 些 实例 来 了 解 一 下 该 扫描 方式 的 特点 。 在 正式 开始 之 前 ,我们 需要 做 一 点 准备 工作 : 


步骤 1 创建 一 下 相关 的 表 和 主键 索引 : 


SQL> create table alex t01 ( 


id number, 
3 a number, 
4 b number, 
5 c number, 
6 name varchar2 (100) 


7 ); 
SQL> alter table alex t01 add constraint pk alex t01 


2 primary key (id) using index; 


步骤 2 初始 化 数据 ， 顺 序 地 插入 10 万 行 数据 : 


SQL> declare 
2 begin 
for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 100000 loop 
4 insert into alex t01 
号 values 
6 (i, mod(i, 2), mod(i, 20000), mod(i, 20000), 'alex'); 
7 end loop; 
8 commit; 
9 end; 
10 
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步骤 3 ”最 重要 的 是 收集 一 下 表 和 主键 索引 的 统计 信息 和 直方 
计划 跑 偏 ， 影 响 性 能 : 


网 


信息 (默认 开启 直方 图 收集 ) ， 在 缺失 统计 信息 和 直方 图 的 情况 下 ，CBO 优 化 器 可 能 无 法 正确 地 计算 SQL 语句 的 执行 成 本 ， 直 接 导致 执行 


SQL> exec dbms_stats.gather table stats ('alex"v "alex t01') 
SQL> exec dbms stats.gather index stats('alex','pk alex t01') 


准备 工作 完成 后 ， 可 以 实际 执行 一 下 查询 SQL 语 句 ， 进 行 如 下 所 示 的 验证 。 


SQL> select id, name from alex t01 where id=400; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | 让 包公 | 2 (0)1 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX TOl | 于 | 10 | 2 (0)1 00:00:01 1 
上 二， 全 | INDEX UNIQUE SCAN | PK ALEX TOl | 于 | (0)1 00:00:01 | 


我 们 看 到 查询 第 选 条 件 为 id=400， 是 一 个 等 值 查询 ， 返 回 唯一 数据 行 ， 执 行 计划 走 的 是 索引 唯一 扫描 方式 。 


如 果 这 里 不 是 等 值 查询 呢 ? 那么 ， 执 行 计划 将 无 法 按 索 引 唯 一 扫描 方式 。 换 而 言 之 ， 有 且 仪 当 唯 一 键 索引 列 上 发 生 等 值 查询 时 ， 才 会 触发 索引 唯一 扫描 ， 返 回 单行 数据 。 这 种 索引 扫描 方式 也 是 最 高 效 


的 索引 扫描 方式 ， 常 见于 主键 索引 的 应 用 场景 。 


我 们 也 可 以 通过 给 SQL 语句 添加 HINT 关 键 字 的 方式 ， 改 变 执行 计划 ， 强 制 SQL 语 句 走 索 引 扫描 ， 如 下 所 示 : 


SQL> select /*+ index (alex t01 pk alex t01) */ id, name 
2 from alex t01 where id=400; 


Oi 索引 唯一 扫描 是 最 高 效 的 索引 扫描 方式 ， 其 只 对 唯一 键 索引 上 的 等 值 查询 有 效 。 


2.1.5 ”索引 范围 扫描 


在 索引 的 使 用 过 程 中 ， 更 多 的 情况 是 返回 多 个 数据 行 。 当 使 用 一 个 索引 存 取 多 行 数据 时 ， 这 种 索引 扫描 方式 称 为 “索引 范围 扫描 ” (INDEX RANGE SCAN) 。 与 索引 唯一 扫描 不 同 ， 索 引 范 围 扫描 可 
以 发 生 在 唯一 键 索引 上 ， 也 可 以 发 生 在 非 唯一 键 索引 上 。 


哪些 情况 会 发 生 索 引 范 围 扫 描 呢 ? 
:在 唯一 索引 列 上 使 用 了 范围 操作 符 〈 如 : >、<、<>、>=、<=、between， 即 不 等 值 查询 ) ; 


“ 对 非 唯一 索引 列 上 进行 的 查询 。 


图 2-4 索引 范围 扫描 


先 来 看 看 第 一 种 情况 ， 在 主键 索引 列 上 进行 非 等 值 查询 ， 筛 选 条 件 为 jd < 4， 返 回 了 3 行 数 据 ， 此 时 的 执行 计划 走 的 不 是 索引 唯一 扫描 了 ， 而 是 索引 范围 扫描 ， 如 下 例 所 示 : 


SQL> select id, name from alex t01 where id<4; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | 于 | 1 |] 3 (0)1 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX TOl | 二 | 10 | 3 (0)1 00:00:01 | 
号; 次 | INDEX RANGE SCAN | PK ALEX TO1 | | |! 2 (0)1 00:00:01 | 


再 来 测试 一 下 第 二 种 情况 ， 为 表 alex_t01 追 加 一 个 单列 索引 和 一 个 组 合 索引 ， 并 收集 相关 统计 信息 和 直方 图 : 


SQL> create index idx alex t01 id ab on alex t01 (a, b); 

SQL> create index idx alex t01 id c on alex t01 (c); 

SQL> exec dbms stats.gather index stats ('alex'v "idqx alex t01 id ab') 
SQL> exec dbms_stats.gather index stats('alex','idx alex t01 id c') 


在 非 唯一 键 索引 idx_alex_t01_id c 的 索引 列 C 上 进行 查询 ， 其 执行 计划 走 的 是 索引 范围 扫描 。 而 在 普通 索引 上 的 查询 ， 不 论 是 否 等 值 查询 ， 也 不 论 返 回 的 数据 行 数 是 多 少 ， 其 执行 计划 均 为 索引 范围 扫 
描 。 索 引 范 围 扫 描 示 例如 下 所 示 : 


SQL> select * from alex t01 where c=100; 


| Id | Operation | Name | Rows | Bytes | Cost | Time | 
| 0 | SELECT STATEMENT | | 5 | 105 | 6| 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX TO1l | 号 :| 105 | 6| 00:00:01 | 
| 二 区 INDEX RANGE SCAN | IDX ALEX TO1 IDC | 5 | | 1| 00:00:01 | 


我 们 也 可 以 通过 给 SQL 语句 添加 HINT 关 键 字 的 方式 ， 改 变 执行 计划 ， 强 制 SQL 语 句 走 索 引 范围 扫描 ， 如 下 所 示 : 


SQL> select /*+ index rs (alex t01 pk alex t01) */ id, name 
2 from alex t01 where id<4; 


当 发 生 索 引 范 围 扫 描 的 时 候 ， 对 索引 列 有 一 个 自动 排序 操作 ， 默 认 情 况 下 是 正 序 (ASC) 输出 返 


回 


的 结果 集 的 ， 也 就 是 INDEX RANGE SCAN ASC。 对 于 本 例 来 说， 以 下 两 名 SQL 语句 是 等 效 的 : 


SQL> select * from alex t01 where c=100; 
SQL> select * from alex t01 where c=100 order by c7 


如 果 在 SQL 语 句 中 要 求 反 序 排序 输出 结果 集 呢 ? 索引 排序 具体 内 容 将 在 接 下 来 的 章节 展开 。 


@ia 索引 范围 扫描 是 最 常见 的 一 种 索引 扫描 方式 ， 在 做 优化 时 ， 需 要 尽 可 能 使 用 的 一 种 方式 。 


2.1.6 ”索引 全 扫描 


对 于 表 来 说 ， 有 全 表 扫 描 ， 同 样 对 于 索引 来 说 ， 也 是 存在 索引 全 扫描 的 。 索 引 全 扫描 (INDEX FULL SCAN) 与 全 表 扫 描 是 非常 类 似 的 ， 如 图 2-5 所 示 ， 它 将 先 扫 描 索 引 全 部 节点 和 条 目 ， 再 选择 对 应 数 
据 进 行 排序 输出 。 索 引 全 扫描 只 在 CBO 模 式 下 才 有 效 。CBO 根 据 统计 数值 得 知 进行 索引 全 扫描 比 进行 全 表 扫 描 更 有 效 时 ， 才 进行 索引 全 扫描 ， 而 且 此 时 查询 出 的 数据 都 必须 从 索引 中 可 以 直接 得 到 。 


[ 


一 般 来 说 哪些 情况 会 使 用 到 索引 全 扫描 呢 ? 


“ 表 和 表 进 行 排序 合并 联 立 (Sort-Merge Join) 查询 的 时 候 ， 排 序 的 列 必须 是 存在 于 索引 中 的 ; 


“ 查询 中 有 order by 和 group by 子 句 的 时 候 ， 子 名 中 所 有 的 列 是 必须 存在 于 索引 中 的 。 


图 2-5 索引 全 扫描 


下 面 是 一 个 简单 索引 全 扫描 的 例子 : 


SQL> select * from alex t01 order by id; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | 100K| 2050K| 560 (2)1 00:00:07 | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX TOl | 100K| 2050K| 560 (2)1 00:00:07 | 
| 2 | INDEX FULL SCAN | PK ALEX TO1 | 100K| |! 191 (2)1 00:00:03 | 


我 们 也 可 以 通过 给 SQL 语句 添加 HINT 关 键 字 的 方式 ， 改 变 执 行 计 划 ， 强 制 SQL 语 句 走 索引 全 扫描 ， 如 下 所 示 : 


SQL> select /*+ index fs (alex t01 pk alex t01) */ * 
2 from alex t01 order by id; 


与 全 表 扫描 相 比 ， 索 引 全 扫描 的 优势 在 哪里 呢 ? 
“ 全 表 扫 描 过 程 是 不 进行 排序 的 ， 必 须 将 数据 全 部 取出 后 再 进行 排序 输出 ， 其 扫描 目标 表 HWM 下 所 有 数据 块 ， 包 括 没有 必要 的 空 块 。 
“ 因为 索引 结构 本 身 就 是 一 个 有 序 的 结构 ， 索 引 全 扫描 在 遍历 索引 的 同时 就 已 经 完成 了 排序 操作 ， 在 输出 结果 的 时 候 是 不 需要 再 排序 的 ， 再 者 其 通过 ROWID 获 取 行 数据 ， 避 免 了 空 块 的 读 取 。 


@i 示 索引 全 扫描 过 程 是 单 块 读 取 ， 其 不 支持 多 块 并 行 的 读 取 ， 输 出 结果 是 有 序 排列 的 。 


2.1.7 ”索引 快速 全 扫描 


索引 快速 全 扫描 (INDEX FAST FULL SCAN) 是 扫描 索引 中 的 所 有 数据 块 ， 与 INDEX FULL SCAN 很 类 似 ， 最 显著 的 区 别 就 是 它 不 对 查询 出 的 数据 进行 排序 ， 即 数据 不 是 以 排序 顺序 被 返回 。 在 这 种 存 
取 方 法 中 ， 可 以 使 用 多 块 读 功 能 ， 也 可 以 使 用 并 行 读 ， 以 便 获 得 最 大 吞吐 量 并 缩短 执行 时 间 。 


看 一 看 下 面 的 例子 ， 复 合 索引 idx_alex_t01 id_ab 的 索引 列 为 (a，b) ， 查 询 的 返回 列 a，b 都 包含 在 索引 列 上 ， 这 个 时 候 的 取 数 操作 直接 就 能 在 索引 上 完成 了 ， 不 需要 再 根据 ROWID 去 表 中 取 数 了 ， 而 
且 没 有 排序 的 需求 。 这 时 执行 计划 走 的 就 是 INDEX FAST FULL SCAN 的 操作 了 。 


SQL> select a, b from alex t01 where b>600; 


| SELECT STATEMPNT | | 97038 | 758K| 83 (4) 1 00:00:01 | 
| INDEX FAST FULL SCAN| IDX ALEX TOl ID AB | 97038 | 758K| 83 (4)1 00:00:01 | 


当 我 们 取 count (*) 的 时 候 ， 同 样 是 不 关心 顺序 的 ， 也 不 需要 排序 操作 ， 该 查询 只 需要 统计 索引 叶 节 点 上 的 索引 条 目 数量 就 可 返回 结果 了 ，INDEX FAST FULL SCAN 是 一 个 非常 好 的 选择 。 在 下 面 的 执 
行 计划 示例 中 ， 我 们 可 以 看 到 ，SORT AGGREGATE 操 作 是 没有 意义 的 ， 因 为 排序 行 数 只 有 1 行 。 


SQL> select count (*) from alex t01; 


| Id | Operation | Name | Rows | Bytes Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | 工 | 5 44 (3)1 00:00:01 | 
| 1 | SORT AGGREGATE | | 1 | 车 | | 
| 2 |] INDEX FAST FULL SCAN| PK ALEX TO1 | 100K| 488K 44 (3)1 00:00:01 | 


我 们 也 可 以 通过 给 SQL 语句 添加 HINT 关 键 字 的 方式 ， 改 变 执 行 计 划 ， 强 制 SQL 语 句 走 索引 快速 全 扫描 ， 如 下 所 示 : 


SQL> select /*+ index ffs (alex t01 idx alex t01 id _ ab) */ a, b 
2 from alex t01 where b>600; 


再 来 对 比 一 下 索引 全 扫描 和 索引 快速 全 扫描 ， 如 表 2-2 所 示 : 


表 2-2 ”索引 全 扫描 与 索引 快速 全 扫描 对 比 


扫描 方式 输出 排序 取 数 效率 


索引 全 扫描 有 序 输出 ， 无 须 额外 排序 单 块 读 ， 不 支持 并 行 
索引 快速 全 扫描 无 序 输 出 ， 需 要 额外 排序 支持 并 行 多 块 读 


@i 示 索引 快速 全 扫描 是 一 种 比较 高 效 的 扫描 方式 ， 在 优化 过 程 中 ， 可 以 尽量 多 使 用 。 


2.1.8 ”索引 跳跃 扫描 


索引 跳跃 扫描 (INDEX SKIP SCAN) 是 Oracle 9i3 引 进 的 一 个 新 特性 ， 其 发 生 在 复合 索引 上 ， 如 果 SQL 语 句 中 WHERE 子 句 只 包含 索引 中 的 部 分 列 ， 且 这 些 列 不 是 索引 的 第 一 列 ， 就 可 能 发 生 INDEX SKIP 
SCAN。 如 果 在 查询 时 ， 第 一 列 没有 被 指定 ， 就 跳 过 它 。 


INDEX SKIP SCAN 除 了 需要 CBO， 并 且 对 表 进 行 过 分 析 外 ， 还 需要 保证 第 一 列 的 distinct 值 非常 小 。Oracle 会 对 复合 索引 进行 逻辑 划分 ， 分 为 多 个 子 索引 ， 可 以 理解 为 索引 从 逻辑 上 被 划分 为 第 一 列 
distinct 值 的 数量 的 子 索 引 ， 每 次 对 一 个 子 索 引进 行 扫描 。 


下 面 通过 一 个 例子 来 分 析 一 下 ， 在 表 alex_t01 上 ， 有 一 个 复合 索引 idx_alex t01 id ab， 索引 列 为 (a，b) ， 查 询 一 下 该 表 A 列 的 distinct 值 的 数量 为 2， 即 只 有 “0” 和 “1” 两 个 键 值 ， 是 满足 了 先决 条 
件 的 。 


SQL> select distinct a from alex t01; 
A 


再 进行 一 次 INDEX SKIP SCAN 类 型 的 查询 ， 示 例如 下 所 示 : 


SQL> select a, b, name from alex t01 where b=600; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT [ | :| 65 | 8 (0) | 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX TOl | 生 2 65 | 8 (0) | 00:00:01 | 
[| INDEX SKIP SCAN | IDX ALEX TO1 ID AB | 5 1 | 全 (0) | 00:00:01 | 


可 以 看 到 COST 开 销 是 非常 小 的 。 如 图 2-6 所 示 ， 此 时 ， 我 们 可 以 理解 成 复合 索引 idx_alex_t01_id_ab (a，b) 逻辑 上 被 拆 分 成 两 个 独立 子 索 引 idx_alex t01 id_ ab <a=0> (b) 和 
idx_alex t01 id ab_<a=1> (b) ，where 子 句 中 b=600 的 查询 将 分 别 对 这 两 个 子 索引 进行 扫描 。 


这 时 ， 如 果 a 列 的 distinct 值 很 多 ， 那 么 复合 索引 idx_alex_t01 id_ab 拆 分 逻辑 子 索引 的 动作 本 身 就 有 不 小 的 开销 ， 查 询 过 程 再 逐个 扫描 子 索引 也 会 增加 开销 ， 相 比 之 下 ，CBO 优 化 器 可 能 会 更 倾向 于 选 
择 全 表 扫 描 。 


我 们 也 可 以 通过 给 SQL 语句 添加 HINT 关 键 字 的 方式 ， 改 变 执行 计划 ， 强 制 SQL 语 句 走 索 引 跳跃 扫描 ， 如 下 所 示 : 


SQL> select /*+ index ss (alex t01 idx _ alex t01 id _ ab) */ a, b, name 
2 from alex t01 where b=600; 


但 是 ， 换 一 个 角度 来 思考 ， 我 们 会 在 设计 索引 的 时 候 设 计 一 个 前 导 列 区 分 度 极 低 的 复合 索引 吗 ?一 般 情况 下 ， 我 们 是 不 会 


SCAN， 其 COST 开 销 将 会 非常 大 的 ， 反 而 成 了 我 们 需要 优化 的 对 象 。 


二 


索引 跳跃 扫描 


ia 在 复合 索引 设计 中 ， 尽 可 能 选择 区 分 度 较 大 的 列 作为 前 导 列 。 如 果 为 了 使 用 INDEX SKIP SCAN 这 个 索引 扫描 方式 而 选择 区 分 度 极 低 的 列 作为 前 导 列 ， 就 是 本 未 倒置 了 。 


2.1.9 ”索引 组 合 扫描 


如 果 一 个 查询 语句 中 ，WHERE 子 句 包含 两 个 筛选 条 件 ， 这 两 个 条 件 都 有 其 单独 的 索引 ， 我 们 是 不 是 可 以 同时 使 用 两 个 索引 呢 ” 答 案 是 肯定 的 。 我 们 可 以 通过 两 个 独立 的 索引 分 别 扫描 ， 再 组 合 起 来 。 在 


Oracle 早 期 的 版 本 中 ， 我 们 可 以 通过 and_equal 方 式 来 实现 。 从 Oracle 10g 开 始 ，and_equal 方 式 已 经 被 废弃 ， 由 index_combine 方 式 取而代之 。 


索引 组 合 (INDEX COMBINE) 最 早 是 出 现在 位 图 索引 上 的 ， 从 Oracle 9i 开 始 ， 默 认可 以 使 


ROWID 信 息 通 过 BITMAP CONVERSION FROM ROWIDS 的 步骤 转换 成 位 图 


进行 


在 B 树 索引 上 ， 


通过 一 个 例子 来 看 一 下 吧 。 在 开始 之 前 ， 我 们 需要 修改 一 下 表 alex_t01 上 的 索引 ， 我 们 需要 删除 掉 组 合 索 引 idx_alex_t01 id ab， 为 b 列 创建 一 个 单列 索引 idx_alex_t01 id_b， 并 重 


SQL 语句 如 下 : 


SQL> drop index idx alex t01 id ab; 
SQL> create index idx alex t01 id b on alex t01 (b); 


SQL> exec dbms_stats. gather : index : stats(' alex', 'idx _alex t01 id b') 


此 时 ，b 列 和 c 列 都 有 了 其 独立 的 单列 索引 ， 且 此 两 列 区 分 度 都 较 高 。 我 们 再 来 做 一 次 基于 b 列 和 c 列 的 组 合 查询 试 试 : 


SQL> select * from alex i 01 W650 S800 and c=600; 
Id 

0 SELECT STATEMENT | | 
1 TABLE ACCESS BY INDEX ROWID | ALEX TO1 | 
2 BITMAP CONVERSION TO ROWIDS | | 
3 BITMAP AND 1 | 
4 BITMAP CONVERSION FROM ROWIDS| | 

此 囊 INDEX RANGE SCAN | IDX ALEX TOl IDB | 
6 BITMAP CONVERSION FROM ROWIDS| | 

加 INDEX RANGE SCAN | IDX ALEX TOl IDC | 

如 果 你 因为 看 到 BITMAP CONVERSION 的 字样 而 感到 担忧 的 话 ， 那 大 可 不 必 ， 


我 们 要 是 强制 查询 只 走 其 中 一 个 索引 呢 ， 情 况 会 如 何 呢 ? 看 一 个 示例 : 


这 部 分 的 COST 基 本 可 以 忽略 ， 这 是 一 个 典型 的 index_combine 例 子 。 


SQL> select /*+index (alex t01,idx alex 七 01 id b)*/ * 
2 from alex t01 where b=600 and c=600; 


Id Operation Name Rows 

0 SELECT STATEMENT 东 
TABLE ACCESS BY INDEX ROWID| ALEX TOl 
沼 蓝 INDEX RANGE SCAN IDX ALEX TO1l ID B 5 


SQL> select /*+index (alex t01,idx alex t01 id c)*/ * 
2 from alex t01 where b=600 and c=6007 


Id Operation Name Rows 

0 SELECT STATEMENT 1 
二 TABLE ACCESS BY INDEX ROWID| ALEX TOl 和- 
* 2 INDEX RANGE SCAN IDX ALEX TO1l ID C 5 


从 上 例 可 以 看 到 ， 不 论 是 走 b 列 的 索引 还 是 走 c 列 的 索引 ， 其 COST 开 销 都 不 如 index_combine 方 式 更 优 。 


换 而 言 之 ， 如 果 我 们 知道 索引 组 合 扫描 的 方式 会 更 优 ， 也 可 以 通过 给 SQL 语句 添加 HINT 关 键 字 的 方式 ， 改 变 执 行 计 划 ， 强 制 SQL 语 句 走 索引 组 合 扫描 ， 示 例如 下 所 示 : 


SQL> select /*+ index combine(alex t01 idx alex t01 id b 
2 idx alex t01 id 6) /rom alex t01 where b=600 and c=600; 


2.1.10 ”索引 联 立 扫 描 


2.1.9 节 说 到 ， 若 一 个 查询 语句 中 ，WHERE 子 句 包含 两 个 都 有 单独 的 索引 筛选 条 件 ， 则 我 们 可 以 


index_combine 扫 描 的 方式 来 进行 优化 ， 但 是 index_combine 仍 然 是 需要 有 回 


们 查询 返回 的 列 都 包含 在 该 两 个 索引 中 ， 我 们 就 可 以 不 用 回 表 取 数 了 ， 直 接 通 过 两 个 索引 的 HASH JOIN 来 完成 就 可 以 了 。 这 个 时 候 需要 用 另 一 个 索引 相关 的 HINT 关 键 字 index join。 


这 么 做 的 。 这 又 意味 着 什么 呢 ? 这 意味 着 在 执行 计划 中 ， 如 果 看 到 INDEX SKIP 


这 个 特性 是 由 隐藏 参数 b tree_bitmap_plans 来 控制 的 。Oracle 将 B 树 索引 中 获得 | 
匹配 ， 完 成 后 通过 BITMAP CONVERSION TO ROWIDS 再 转换 出 ROWID 获 得 数据 或 者 回 表 获 得 数据 。 


通过 下 面 的 例子 来 看 一 下 ，CBO 优 化 器 更 倾向 于 COST 更 低 的 index_combine 扫 描 ， 强 制 执行 计划 | 
势 的 。 


SQL> select /*+ index join(alex t01 idx alex t01 id b 
2 idx alex t01 id c) */ b, c from alex t01 where b=600 and c=600; 


Eindex_join 扫 描 ，COST 较 index_combine 扫 描 要 高 一 些 ， 但 是 相对 单一 索引 的 使 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | | 10 | 3 (34)| 00:00:01 
Il* 1 | VIEW | index$ join$ 001 | | 其 让 3 (34)| 00:00:01 
I* 2 | HASH JOIN | 证 | | | | 

陵 - 海 | INDEX RANGE SCAN| IDX ALEX TO1L ID B | 芋 咱 10 1 1 (0)1 00:00:01 
I 人 | INDEX RANGE SCAN| IDX ALEX TO1 IDC | 1 1 10 | 1 (0)| 00:00:01 


严格 意义 上 讲 ，index_combine 和 index_join 都 不 能 算是 一 种 独立 的 索引 扫描 方式 ， 它 们 是 对 现 有 五 种 索引 扫描 方式 的 优化 和 补充 ， 使 : 


人 @ 证 示 INDEX COMBINE 和 INDEX JOIN 扫描 方式 各 自 有 其 适用 场景 ， 合 理 的 使 用 索引 组 合 和 索 


如 果 索 引 结构 设计 比较 合理 ， 则 能 在 索引 扫描 过 程 中 完成 取 数 的 操作 ， 尽 量 在 索引 扫描 中 完成 ， 避 免 回 表 取 数 的 开销 ， 这 个 技巧 叫做 索引 


(select、where、order by、group by) ， 用 来 提高 查询 的 效率 。 


引 联 立会 带 来 性 能 的 大 幅 提升 。 


履 盖 应 用 (INDEX COVERING) ， 它 履 盖 


来 说 ， 却 是 有 优 


获得 更 好 的 性 能 优势 。 


了 查询 的 所 有 字段 


纵 观 各 种 索引 扫描 方式 的 介绍 和 分 析 ， 每 种 扫描 方式 都 有 其 特点 和 适用 场景 ， 不 能 单纯 地 说 哪 种 扫描 方式 更 优 。 在 优化 的 工作 中 ， 更 不 能 简单 地 用 某 种 扫描 方式 去 替代 另 一 种 扫描 方式 ， 我 们 需要 分 析 


清楚 具体 的 应 用 场景 ， 根 据 业 务 需求 选择 合适 的 索引 扫描 方式 。 


就 需要 通过 比较 不 同 索引 扫描 方式 下 ，SQL 语 句 执行 的 响应 时 间 来 判断 。 


2.2 索引 与 排序 


通过 2.1 节 的 介绍 ， 我 们 知道 了 索引 扫描 是 可 以 优化 排序 的 ， 索 引 扫描 输出 的 结果 是 有 序 排列 的 (索引 快速 全 扫描 除外 ) ， 为 什么 会 这 样 呢 ， 难 道 索引 输出 的 时 候 


该 说 索引 本 身 就 是 一 种 有 序 排列 的 数据 结构 。 索 引 在 建立 条 目的 时 候 ， 就 已 经 将 其 按照 索引 列 的 顺序 进行 顺序 存储 ， 这 和 表 的 存储 结构 是 不 一 样 的 。 


如 果 统计 信息 和 直方 图 收集 得 准确 的 话 ，CBO 优 化 器 会 提供 准确 的 COST 开 销 估算 ， 可 以 作为 索引 扫描 方式 选择 的 参考 。 在 实际 优化 的 工作 中 ， 我 们 往往 不 能 获得 足够 准确 的 统计 信息 和 直方 图 信息 ， 


动 做 了 一 次 排序 吗 ? 其 实 不 是 的 ， 应 


之 所 以 将 排序 这 个 话题 单 拿 出 来 讲 ， 主 要 是 为 了 说 明 一 个 排序 的 道理 。 很 多 人 可 能 有 意 无 意 地 忽略 了 SQL 语 句 中 的 排序 这 块 ， 其 实 很 多 时 候 ， 避 免 排 序 可 以 大 大 提升 SQL 语 句 的 性 能 ， 这 是 非常 重要 的 


一 点 。 不 论 作 为 开发 者 还 是 管理 者 ， 都 需要 时 刻 保持 对 排序 的 敏感 。 很 多 时 候 ， 临 时 表 空 间 使 用 率 超 限 ， 
时 表 空 间 是 磁盘 排序 ， 在 速度 上 和 内 存 排序 是 无 法 比拟 的 。 


本 节 将 围绕 索引 这 种 有 序 结构 与 排序 优化 展开 介绍 ， 让 读者 充分 了 解 到 索引 对 优化 排序 的 作用 。 


2.2.1 _B 树 索引 内 部 结构 


我 们 已 经 了 解 到 B 树 索引 是 一 种 典型 的 树 形 结构 ， 其 包含 的 组 件 主要 是 : 
“ 根 节 点 : 只 有 一 个 根 节点 ， 是 位 于 树 的 最 顶端 的 分 支 节点 ; 
: 分支 节点 : 存储 指针 指向 索引 里 其 他 的 分 支 节点 或 者 叶 节 点 ; 


“ 叶子 节点 : 存储 索引 条 目 〈 包 括 索 引 条 目 头 信息 、 索 引 键 值 长 度 、 索 引 键 值 ， 以 及 ROWID 相 关 信 


查询 速度 太 慢 都 可 能 是 因为 排序 太 多 ，PGA 内 存 排序 | 


息 ) 直接 指向 表 里 的 数据 行 。 


区 装 不 下 ， 不 得 不 放 到 临时 表 空 间 去 排 


序 ,， 临 


下 面 通过 一 张 示 意图 来 描述 一 下 这 种 内 部 结构 ， 如 图 2-7 所 示 ， 就 分 支 节点 块 (包括 根 节点 块 ) 来 说 ， 其 所 包含 的 索引 条 目 都 是 按照 顺序 排列 的 默认 是 ASC 升 序 排列 ， 也 可 以 在 创建 索引 时 指定 为 
DESC 降 序 排列 ) 。 每 个 索引 条 目 均 由 两 个 字段 组 成 ， 第 一 个 字段 表示 当前 该 分 支 节点 块 下 所 指向 的 叶 节 点 块 中 所 包含 的 开始 键 值 (对 升序 排序 的 索引 来 说 ， 就 是 最 小 键 值 ) ， 第 二 个 字段 为 指向 叶 节 点 块 地 
址 的 指针 。 在 一 个 分 支 节点 块 中 所 能 容纳 的 记录 行 数 由 数据 块 大 小 以 及 索引 键 值 的 长 度 决定 。 在 本 例 中 ， 对 于 根 节点 块 来 说， 包含 三 个 指针 ， 分 别 为 (1 B1) 、 (100 B2) 、 (200 B3) ， 它 们 指向 三 个 分 
支 节点 块 。 其 中 的 1、100 和 200 分 别 表示 这 三 个 分 支 节点 块 所 指向 的 开始 键 值 ， 而 8B1、B2 和 B3 则 表示 所 指向 的 三 个 分 支 节点 块 的 地 址 。 


对 于 叶子 节点 块 来 说， 其 所 包含 的 索引 条 目 与 分 支 节点 一 样 ， 都 是 按照 顺序 排列 的 。 每 个 索引 条 目 也 包含 两 个 字段 。 第 一 个 字段 表示 索引 的 键 值 ， 对 于 和 


是 多 个 值 组 合 在 一 起 的 。 第 二 个 字段 表示 该 键 值 所 对 应 的 数据 行 的 ROWID， 该 ROWID 是 数据 行 在 表 里 的 物理 地 址 。 


a 列 索引 来 说 是 一 个 值 ， 而 对 于 复合 索引 来 说 则 


当 有 新 的 索引 键 值 插入 的 时 候 ， 索 引 会 判断 新 键 值 的 排序 位 置 。 如 果 新 键 值 大 于 目前 索引 存储 的 最 大 值 ， 则 会 将 新 键 值 插 入 到 最 右 侧 的 叶 节 点 块 (L8) 上 ， 如 果 新 键 值 为 198， 则 会 将 其 插入 到 节点 块 


L6 上 。 如 果 对 应 叶 节 点 块 已 满 ， 则 会 分 裂 出 新 的 叶 节点 块 ， 分 支 节点 块 满 了 ， 同 样 会 分 裂 出 新 块 。 


Root 
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40R3 65R5 110R7 143R9 170R11| |201R13| |240R15 
35R4 90R6 127R8 152R10| |190R12| |202R14| |242R16 
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图 2-7 B 树 索引 内 部 结构 


索引 这 个 特点 是 不 同 于 表 的 ，DML 操 作 过 程 中 ， 对 索引 维护 成 本 是 比较 大 的 ， 所 以 我 们 需要 定期 地 去 分 析 索 引 的 结构 ， 保 证 其 高 效 支持 查询 的 能 力 。 


2.2.2 ”输出 排序 


在 使 用 索引 优化 查询 的 过 程 中 ， 一 方面 是 通过 索引 扫描 快速 定位 返回 行 的 ROWID， 另 一 方面 则 是 利用 索引 的 有 序 结构 避免 一 些 不 必要 的 排序 操作 。 


下 面 我 们 将 结合 2.1 节 中 介绍 的 五 种 索引 扫描 方式 来 讨论 一 下 使 用 索引 扫描 输出 结果 集 的 排序 问题 吧 。 


“ 索引 唯一 扫描 : 这 种 扫描 方式 ， 输 出 的 结果 集 只 有 一 个 记录 行 ， 就 不 存在 排序 的 问题 ; 
“ 索引 范围 扫描 : 该 方式 是 索引 排序 最 典型 的 应 用 ， 其 输出 结果 集 都 是 有 序 的 《升序 输出 还 是 降序 输出 取决 于 索引 创建 时 的 参数 ， 默 认为 升序 ) ; 
“ 索引 全 扫描 : 这 个 方式 可 以 看 做 是 全 范围 的 扫描 ， 其 效果 和 索引 范围 扫描 是 一 样 的 ; 


“ 索引 快速 全 扫描 : 从 字面 上 来 看 ， 和 索引 全 扫描 非常 相像 ， 但 两 者 是 完全 不 同 的 两 种 方式 ， 快 速 全 扫描 的 输出 结果 集 是 不 排序 的 ， 如 果 WHERE 子 句 中 要 求 ORDER BY， 则 需要 额外 的 排序 开销 ; 


“ 索引 跳跃 扫描 : 可 以 视 作 是 分 拆 成 多 个 远 辑 子 索引 后 的 INDEX COMBINE 扫 描 ， 对 于 逻辑 子 索引 的 扫描 即 为 索引 范围 扫描 或 者 索引 全 扫描 。 


下 面 我 们 通过 几 个 实例 对 比 来 具体 分 析 一 下 几 个 比较 典型 的 扫描 方式 的 排序 情况 : 索引 范围 扫描 、 索 引 快 速 全 扫描 、 索 引 跳跃 扫描 。 


1. 索 引 范围 扫描 排序 


首先 ， 要 创建 一 个 测试 表 ，2.1 节 的 alex_t01 表 都 是 顺序 插入 的 连续 性 数据 ， 这 对 于 排序 的 识别 有 些 困难 ， 我 们 重新 创建 一 个 表 alex_t02， 修 改 b 列 和 <c 列 的 数据 为 随机 数 插入 。 具 体 步骤 和 SQL 语句 如 下 
所 示 : 


步骤 1 创建 表 ALEX_T02， 及 主键 索引 和 普通 索引 : 


SQL> create table alex t02 ( 
id number, 
3 a number, 
4 b number, 
号 c number, 
6 name varchar2 (100) 
7 ); 
SQL> alter table alex t02 add constraint pk alex t02 
2 primary key (id) using index; 
SQL> create index idx alex t02 ab on alex t02 (a, b); 
SQL> create index idx alex t02 c on alex t02 (c); 


步骤 2 初始 化 数据 ， 随 机 插入 10 万 行 数据 : 


SQL> declare 
2 begin 
3 for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 100000 loop 
4 insert into alex 七 02 
号 values 
6 位 7 
时 mod(i, 2), 
8 trunc (dbms_random.value (1, 20000)), 
9 trunc (dbms random.value (1, 20000)), 
10 dbms_random.string('X', 10)); 
11 end loop; 
12 commit; 
13 eng; 
多 光 


步骤 3 ”收集 表 和 索引 的 统计 信息 及 直方 图 信息 : 


SQL> exec dbms_ stats.gather table stats('alex','alex t02') 
SQL> exec dbms_ stats.gather index stats('alex','pk alex t02') 


SQL> exec dbms_ stats.gather index stats('alex','idx alex t02 ab') 
SQL> exec dbms_ stats.gather index stats('alex','idx alex t02 c') 


不 进行 排序 操作 ， 先 来 对 比 一 下 全 表 扫 描 和 索引 扫描 的 输出 结果 。 如 下 例 所 示 ， 可 以 看 到 ， 索 引 扫 描 输 出 的 结果 是 有 序 的 (对 c 列 采用 默认 的 升序 排列 ) ， 全 表 扫 描 则 是 无 序 的 其 结果 的 顺序 为 数据 实 
际 入 库 的 顺序 ) 。 


SQL> select /*+full (alex t02)*/ id，c 
2 from alex t02 where c<3; 
ID 


92069 
11 rows selected. 
SQL> select /*+index(alex t02 idx alex t02 c)*/ id, c 
2 from alex t02 where c<3; 
ID a 


89903 
11 rows selected. 


如 果 需 要 全 表 扫 描 的 输出 与 索引 扫描 一 致 ， 就 需要 进行 一 次 额外 的 排序 (order by c) 操作 。 如 下 所 示 ， 在 SQL 语 句 执行 的 统计 信息 中 多 了 一 次 内 存 排序 操作 : 


SQL> select /*+full (alex t02)*/ id, c 
2 from alex t02 where c<3 order by c; 
Statistics 
1 sorts (memory) 
0 sorts (disk) 
11 rows processed 


如 果 我 们 使 用 的 是 索引 范围 扫描 的 话 ， 即 使 我 们 添加 了 order by 子 句 ， 声 明 需 要 排序 操作 ， 但 是 CBO 优 化 器 也 会 忽略 掉 这 个 要 求 ， 在 执行 后 的 统计 信息 中 也 没有 出 现任 何 排 序 ， 如 下 所 示 : 


SQL> select /*+index rs (alex t02 idx alex t02 c)*/ JS 
2 from alex t02 where c<3 order by c; 
Statistics 和 
0 sorts (memory) 
0 sorts (disk) 
11 rows processed 


@ 注 意 在 索引 扫描 取 数 的 时 候 ， 对 索引 列 进行 ORDER BY 是 没有 必要 的 (索引 快速 全 扫描 除外 ) 。 


2. 索 引 跳 跃 扫描 排序 


前 面 介绍 过 索引 跳跃 扫描 其 实 是 将 复合 索引 打 散 成 还 辑 上 的 子 索引 ， 再 进行 扫描 。 基 于 这 个 原理 ， 我 们 可 以 想象 到 ， 子 索引 和 子 索引 之 间 的 关系 是 按照 复合 索引 的 前 导 列 的 顺序 有 序 组 织 的 ， 子 索引 内 
部 则 是 按照 子 索 引 的 键 值 的 顺序 有 序 组 织 的 。 各 个 子 索 引 对 应 输出 的 子 结果 集 也 具有 同样 的 顺序 关系 。 


在 下 面 的 例子 中 ，order by 子 句 要 求 的 排序 方式 为 (a，b) ， 这 和 复合 索引 的 默认 顺序 是 一 致 的 ， 所 以 子 结果 集 直接 输出 即 可 ， 不 必 人 额外 的 排序 ， 最 终 看 到 的 统计 信息 中 的 排序 次 数 为 0。 


SQL> select /*+ index ss (alex t02 idx alex t02 ab) */ 
2 a, b, name from alex t02 where b<600 order by a, b; 
Statistics 
0 sorts (memory) 
0 sorts (disk) 
3003 rows processed 


如 果 order by 子 句 要 求 的 排序 方式 和 复合 索引 结构 的 默认 顺序 不 一 致 呢 ? 如 下 例 所 示 ，b 列 的 数据 是 随机 生成 的 ， 本 是 无 序 的 。 在 各 个 子 结果 集 内 部 ， 由 于 索引 有 序 结构 的 关系 ，b 列 是 有 序 排列 的 ， 但 
在 各 个 子 结果 集 之 间 比 较 ，b 列 则 是 无 序 的 。 比 如 : 子 结果 集 (a=0) 中 可 能 存在 b={1，2，3， 沙 ， 子 结果 集 (a=1) 中 可 能 存在 b={1，3，5，6}， 如 果 按照 复合 索引 的 默认 顺序 (order by a，b) 输出 则 
是 b={1，2，3，4，1，3，5，6}， 如 果 按 照 子 索引 键 值 顺序 (order by b) 输出 ， 则 是 b={1，1，2，3，3，4，5，6}, 后 者 的 输出 意味 着 需要 一 次 额外 的 排序 。 


SQL> select /*+ index ssl(alex t02 idx alex t02 ab) */ 
2 a, b, name from alex t02 where b<600 order by b; 
Statistics 
1 sorts (memory) 
0 sorts (disk) 
3003 rows processed 


3. 索 引 快速 全 扫描 排序 


现在 我 们 知道 了 对 于 复合 索引 来 说 ，order by 子 句 要 求 排序 的 列 正好 在 复合 索引 键 上 是 可 以 避免 不 必要 的 排序 的 ， 但 是 这 里 也 有 一 个 例外 ， 就 是 索引 快速 全 扫描 的 情况 。 前 面 提 到 该 扫描 方式 是 不 支持 
排序 输出 的 ， 如 果 指明 order by 的 话 ， 会 需要 额外 的 排序 操作 ， 而 且 此 排序 的 COST 开 销 非 常 大 ， 如 下 例 所 示 : 


SQL> select /*+index ffs (alex t02 idx alex t02 ab)*/ a, b 
2 from alex t02 where b>600 order by a,b; 


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| 
| 0 | SELECT STATEMENT | 97005 | 757K]| | 423 (2)1 
| 1 | SORT ORDER BY i |-97005 | 757K| 1536K| 423 (2)1 
| 二 坚 | INDEX FAST FULL SCAN| IDX ALEX T02 AB | 97005 | 757K| | 66 (2) | 


1 sorts (memory) 
0 sorts (disk) 


96993 rows processed 


细心 的 读者 可 能 已 经 注意 到 ， 上 例 中 添加 了 HINT 关 键 字 强制 执行 计划 ， 而 且 执 行 计划 中 的 COST 开 销 是 比较 大 的 ， 如 果 去 掉 HINT 呢 ? 结果 如 下 : 


SQL> select a, b from alex t02 where b>600 order by a,b; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | 1 27008 | 757K| 292 (1)| 
I* 1 | INDEX FULL SCAN | IDX ALEX T02 AB | 97005 | 757K]| 292 [和 儿 加 | 
Statistics 


0 sorts (memory) 
0 sorts (disk} 
96993 rows processed 


从 执行 计划 中 可 以 看 到 ， 快 速 全 扫描 被 全 扫描 代替 了 ，COST 开 销 反而 降低 了 。 一 般 情 况 下 ， 快 速 全 扫描 的 效率 是 要 比 全 扫描 高 的 ， 此 时 CBO 为 什么 反而 选择 全 扫描 的 方式 呢 ? 原 因 就 出 在 排序 上 。 


@@ 注 总 对 于 大 结果 集 的 输出 ， 尽 量 避 免 不 必 要 的 排序 ， 如 果 能 用 索引 排序 进行 优化 ， 也 请 尽量 使 用 。 


2.2.3 ”降序 索引 


看 到 这 里 ， 有 的 读者 可 能 会 问 到 ， 我 们 一 直 都 是 在 说 升序 的 情况 ， 如 果 要 求 降序 查询 呢 ， 情 况 是 否 会 不 一 样 呢 ? 是 的 ,会 不 一 样 。 我 们 接 下 来 将 围绕 这 个 索引 降序 的 话题 来 说 一 说 。 


我 们 可 以 从 单列 索引 和 复合 索引 两 个 维度 来 进行 阐述 。 当 然 ， 在 阅 述 之 前 ， 先 介绍 一 个 新 的 概念 ， 就 是 “降序 索引 ”。 


1. 降 序 索 引 


什么 是 降序 索引 呢 ? 其 实 降序 索引 也 是 B 树 索引 ， 只 是 将 通常 意义 上 的 B 树 索引 中 的 存储 方式 从 升序 变 成 了 降序 ， 如 果 应 用 场景 中 经 常会 出 现 降序 排序 的 查询 ， 建 立 一 个 降序 B 树 索引 不 失 为 一 个 很 好 的 
选择 。 


默认 情况 下 建立 的 B 树 索引 均 为 升序 (ASC) 索引 ， 语 名 如 下 : 


SQL> create index idx alex t02 c on alex t02 (c); 


如 果 需 要 建立 降序 (DESC) 索引 ， 只 需要 在 索引 列 后 注 明 “desc” 关 键 字 ， 语 句 如 下 : 


SQL> create index idx alex t02 c on alex t02 (c desc) 


2. 单 列 索引 的 降序 


对 于 单列 索引 来 说， 进行 升序 查询 的 时 候 ， 其 实 就 是 按照 从 左 到 右 的 顺序 逐一 扫描 索引 的 叶 节 点 块 。 这 个 动作 是 否 可 以 反 过 来 进行 呢 ， 从 右 到 左 地 去 扫描 ?答案 是 肯定 的 ， 这 样 就 是 降序 查询 的 优化 
了 ， 即 使 我 们 建 索引 的 时 候 是 按照 升序 来 建 的 ，CBO 优 化 器 也 可 以 自动 进行 降序 查询 优化 。 


下 面 是 一 个 降序 查询 的 例子 ， 在 升序 索引 上 的 扫描 ， 不 论 是 升序 查询 ， 还 是 降序 查询 ， 都 没有 额外 的 排序 操作 ， 而 且 CBO 计 算出 来 的 COST 开 销 也 是 一 致 的 。 


SQL> select id, name from alex t02 where c<=6 order by c¢; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | :| 105 | 8 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX T02 | 51 105 | 8 (0) | 
|* 妈 |] INDEX RANGE SCAN | IDX ALEX TO2 C | | | 2 (0) | 
Statistics 

0 sorts (memory) 

0 sorts (disk) 

33 rows processed 

SQL> select id, name from alex t02 where c<=6 order by c¢ desc; 
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 


0 | SELECT STATEMENT | | :| 8 | 
1 | TABLE ACCESS BY INDEX ROWID | ALEX T02 | 5 | 105 | 8 (0) | 
2 1 INDEX RANGE SCAN DESCENDING| IDX ALEX T02 C | § 1 2 | 


0 sorts (memory) 
0 sorts (disk) 
33 rows processed 


同 理 可 知 ， 如 果 我 们 建立 的 是 降序 索引 ，CBO 优 化 器 也 会 自动 对 升序 查询 进行 优化 ， 同 样 不 会 有 额外 的 COST 开 销 。 但 是 ， 降 序 索引 上 的 升序 扫描 会 被 识别 为 降序 操作 。 


is 示 所 以 ， 对 于 单列 索引 来 说 ， 没 有 必要 刻意 创建 降序 索引 ， 默 认 的 升序 索引 是 可 以 支持 降序 查询 的 ， 并 且 自动 优化 ， 不 会 产生 额外 的 COST 开 销 。 


3. 复 合 索引 的 降序 


如 果 说 升序 索引 上 进行 降序 查询 可 以 自动 优化 ， 那 还 需要 降序 索引 干什么 呢 ? 它 的 作 表现 在 复合 索引 的 应 用 上 。 


我 们 通过 几 个 例子 来 分 析 一 下 其 应 用 场景 ， 先 清理 掉 之 前 的 索引 ， 在 (b，c) 列 上 创建 一 个 复合 索引 。SQL 语 句 如 下 所 示 : 


SQL> drop index idx alex t02 ab; 

SQL> drop index idx alex t02 c; 

SQL> create index idx alex t02 bc on alex t02 (b, c); 

SQL> exec dbms_ stats.gather index stats('alex','idx alex t02 bc') 


此 时 , 在 (b，c) 列 上 进行 (b asc，c asc) 的 排序 操作 ， 很 显然 是 不 会 有 额外 排序 的 ， 复 合 索引 两 个 索引 列 都 是 升序 组 织 起 来 的 。 示 例如 下 : 


SQL> select id, name from alex 七 02 
2 where b<=400 and c<=400 order by b, c; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 


| 0 | SELECT STATEMENT | 40 | 1040 | 47 (0) | 
| 1 | TABLE ACCESS BY INDEX | ALEX TO02 | 40 | 1040 | 47 (0) | 
呈 有 INDEX RANGE SCAN | IDX 7 RTEX _T02_BC 40 对 (0) | 
Statistics 


0 sorts (memory) 
0 sorts (disk) 
41 rows processed 


将 排序 条 件 修改 一 下 ， (b desc，c asc) ，b 列 降序 ，c 列 升序 。 先 来 想象 一 下 ， 此 刻 b 列 需要 降序 ，CBO 优 化 器 可 以 自动 优化 ， 让 b 列 的 从 大 到 小 地 读 ， 也 就 是 叶 节 点 块 从 右 往 左 地 扫描 ， 这 没有 问 
题 。 但 不 幸 的 是 ，c 列 则 需要 从 左 往 右 地 扫描 ， 这 就 发 生 矛盾 了 。 解 决 矛盾 的 方式 就 是 额外 进行 一 次 排序 ， 示 例如 下 所 示 : 


SQL> select id, name from alex t02 
2 where b<=400 and c<=400 order by b desc, c; 


| Id | Operation | Name | Rows | 
| 0 | SELECT STATEMENT | 1 40 | 
[ 1 | SORT ORDER BY | | 40 | 
| 2 | TABLE ACCESS BY INDEX RONID| ALEX T02 | 40 | 
| INDEX RANGE SCAN | IDX ALEX T02 BC | 40 | 
Statistics 


1 sorts (memory) 
0 sorts (disk) 
41 rows processed 


我 们 说 一 切 应 从 适合 应 用 场景 出 发 ， 如 果 应 用 场景 中 ， 经 常 要 求 (b desc，c asc) 的 排序 方式 ， 那 我 们 就 应 该 创建 一 个 如 下 的 降序 索引 : 


SQL> drop index idx alex 七 02 bc; 
SOL> create index idx alex t02 bc on alex t02 (b desc, c); 
SQL> exec dbms_stats. gather : index :stats(' alex', 'idx alex t02 bc') 


新 的 索引 创建 完成 ， 再 来 执行 一 下 上 面 的 两 个 SQL 语句 看 看 。 此 时 的 情况 完全 反 过 来 了 ， (b desc，c asc) 没有 额外 排序 ,而 (b asc，c asc) 有 了 。 


SQL> select id, name from alex t02 
2 where b<=400 and c<=400 order by b, c; 
Statiatics 
1 sorts (memory) 
0 sorts (disk) 
41 rows processed 
SQL> select id, name from alex t02 
2 where b<=400 and c<=400 order by b desc, c; 
Statistics 
0 sorts (memory) 
0 sorts (disk) 
41 rows processed 


此 处 ， 我 们 不 妨 再 引申 一 下 。 现 在 的 索引 顺序 是 (b desc，c asc) ， 如 果 SQL 语 句 要 求 的 排序 输出 的 方式 变 为 (b asc，c desc) 呢 ? 如 果 你 能 像 刚 才 一 样 想 象 一 下 ， 就 不 难得 到 答案 。 此 时 ，b 列 和 c 
列 都 是 要 求 从 右 往 左 地 扫描 索引 叶 节 点 块 ，CBO 优 化 器 可 以 通过 INDEX RANGE SCAN DESCENDING 的 方式 优化 执行 计划 ， 其 过 程 不 会 有 额外 的 排序 和 COST 开 销 。 示 例如 下 所 示 : 


SQL> select id, name from alex 七 02 
2 where b<=400 and c<=400 order by b，c desc; 


| Id | Operation | Name | Rows | Bytes | Cost 


0 | SELECT STATEMENT | | 
1 | TABLE ACCESS BY INDEX ROWID | ALEX T02 | 40 | 1040 | 
2 | INDEX RANGE SCAN DESCENDING| IDX ALEX T02 BC | 


0 sorts (memory) 


0 sorts (disk) 
41 rows processed 


降序 索引 在 日 常 工 作 中 ， 尤 其 是 做 报表 和 大 数据 分 析 应 用 的 SQL 语句 ， 应 该 能 发 挥 比较 积极 和 重要 的 作用 。INDEX RANGE SCAN DESCENDING 的 扫描 优化 方式 也 不 能 忽略 ， 这 种 优化 方式 对 于 
INDEX FULL SCAN 同 样 适用 。 


ja 降序 索引 和 降序 扫描 在 索引 的 排序 应 用 中 有 积极 的 意义 。 根 据 实际 应 用 情况 ， 选 择 合适 的 索引 组 织 形 式 ， 往 往 可 以 事半功倍 的 。 


2.2.4 聚合 查询 min () 与 max () 


前 面 的 章节 中 ， 我 们 提 到 COUNT (*) 的 聚合 查询 可 以 利用 索引 扫描 来 规避 回 表 取 数 的 动作 ， 而 且 索引 扫描 过 程 也 可 以 选择 INDEX FAST FULL SCAN 的 高 效 方式 。 现 在 ， 我 们 再 来 说 说 另 一 种 聚合 查询 
min () 与 nax () 。 这 个 和 索引 有 关系 吗 ， 能 用 到 索引 进行 优化 吗 ? 也 许 有 读者 会 说 : “是 的 ， 但 索引 列 必须 要 有 NOT NULL 的 约束 ， 或 者 在 查询 过 程 中 过 滤 掉 NULL。” 这 个 回答 是 值得 鼓励 和 肯定 的 。 
但 是 ， 另 一 个 问题 出 来 了 ， 它 能 用 到 哪 种 索引 扫描 方式 呢 ? 像 COUNT (*) 一 样 ，INDEX FAST FULL SCAN 吗 ? min () 与 max () 是 依赖 于 顺序 的 ， 能 接受 不 排序 的 输出 吗 ? 


下 面 的 例子 告诉 我 们 ， 在 主键 索引 列 上 的 min () 与 max () ， 是 可 以 用 到 索引 快速 全 扫描 的 ， 而 且 COST 下 降 比较 明显 ， 达 到 了 优化 的 目的 。 


SQL> select 0 (alex t02)*/ min (id) ，max(id) 
2 from alex : 


0 SELECT STATEMENT | | 

1 SORT AGGREGATE 1 工 | 5 | | 
2 TABLE ACCESS FULL| ALEX T02 | 

SQL> select /*+index fs (alex t02 pk alex t02)*/ min(id), max(id) 

2 from alex t02; 


0 SELECT STATEMENT 4 | | 
1 SORT AGGREGATE | | 工 | | | 
2 INDEX FAST FULL SCAN| PK ALEX T02 | | 


我 们 说 主键 索引 的 键 值 具有 唯一 性 ， 而 且 顺 序 排列 ， 这 固然 能 用 到 INDEX FAST FULL SCAN,， 而 如果 是 有 重复 性 的 非 唯 一 索引 呢 ? 就 只 能 走 INDEX FULL SCAN 了 ， 甚 至 可 能 会 因为 COST 太 高 ， 而 选 
择 走 全 表 扫 描 。 
不 知道 有 没有 读者 还 沉浸 在 我 们 之 前 的 想象 中 呢 ? 如 果 有 ， 相 信 你 已 经 想象 到 了 更 好 的 优化 方法 。 我 们 都 知道 索引 的 树 形 结构 ， 各 层 节点 块 都 是 有 序 排列 的 ， 默 认 升 序 的 情况 下 ， 从 左 到 右 即 是 从 小 到 


大 ，min () 就 是 最 左 叶 节 点 块 ，max () 则 是 最 右 叶 节点 块 。 想 象 完成 ， 通 过 实例 来 验证 一 下 吧 。 


从 下 面 的 例子 可 以 看 到 ， 执 行 计 划 变 成 了 索引 全 扫描 的 方式 ， 但 是 多 了 (MIN/MAX) 的 字样 。 这 是 CBO 优 化 器 对 索引 全 扫描 的 一 个 优化 ， 其 间 萤 藏 着 一 个 STOPKEY 的 机 制 ， 简 单 来 说 ， 就 是 扫描 到 需 
要 的 东西 就 退出 ， 不 继续 扫描 了 。 执 行 计划 中 INDEX FULL SCAN (MIN/MAX) 的 COST 开 销 只 有 2， 较 之 INDEX FAST FULL SCAN 更 优 。 


SQL> select min (id) from alex 七 027 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 1 | 5 | 2 

| 1 1 SORT AGGREGATE | | 工 5 | 

| 21 INDEX FULL SCAN (MIN/MAX)| PK ALEX T02 | 100K| 488K| 2 


细心 的 读者 应 该 注意 到 了 ， 上 


STOPKEY 机 制 的 特性 来 提高 查询 性 能 ， 甚 至 可 以 通过 改写 SQL， 将 原本 用 不 到 该 特性 的 查询 利用 上 ， 
再 多 说 一 句 关 于 STOPKEY 特 性 的 应 用 ， 在 TOP-N 的 查询 或 者 分 页 查询 中 ， 它 的 作用 是 不 容 小 凯 的 。 示 例如 下 所 示 : 
SQL> select * from (select id, name from alex t02 order by id desc) 
where rownum<=10; | 

| Id | Operation | Name | Rows | Bytes Cost (%CPU)| 

| 0 | SELECT STATEMENT 上‘ 10 | 650 3 (0) | 

|* 1 | COUNT STOPKEY | | | | 

| 2 | VIEW | | 40 | 650 3 (0) | 

| 3 | TABLE ACCESS BY INDEX ROWID| ALEX T02 | 100K| 1562K 3 (0) | 

| 4 1 INDEX FULL SCAN DESCENDING| PK ALEX TO2 | 10.1 有 (0) | 


么 从 右 到 左 ， 现 在 是 需要 


SQL> select min(id), max(id) from alex 七 027 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 工 | 5 | 45 (5) | 
| 1 | SORT AGGREGATE | | | -| 1 
| 受 二 INDEX FAST FULL SCAN| PK ALEX T02 | 100K| 488K| 45 (5) | 


面 的 SQL 语句 只 做 了 min () ， 并 没有 同时 取 min () 与 max () ， 同 时 取 的 话 ， 是 什么 效果 呢 ? 下 面 的 例子 告诉 我 们 ， 仍 然 会 走 INDEX FAST FULL SCAN。 原 
单 ， 索 引 扫 描 只 能 是 单 向 的 扫描 ， 要 么 从 左 到 右 ， 
SCAN (MIN/MAX) 就 未 被 使 用 。 


很 简 


同时 返回 min () 和 max () ， 如 果 STOPKEY 在 取 到 min () 退出 ， 就 取 不 到 max () ， 反 之 亦 然 。 所 以 ，INDEX FULL 


但 事实 上 ， 从 COST 计 算 来 看 ， 即 使 单独 取 一 次 min () ， 再 单独 取 一 次 max () ， 


SQL> select (select min (id) from alex t02) min value, 


2 (select max(id) from alex t02) max Value from dual; 

| Id Operation | Name | Rows | Bytes | Cost (%CPU) 
| 0 SELECT STATEMENT | | 1 | 六 

| 1 SORT AGGREGATE | | 1 -| 

| 2 INDEX FULL SCAN (MIN/MAX)| PK ALFX TO2 | 100K| 488K| 2 

| 3 SORT AGGREGATE | | 1 :| 

| 4 INDEX FULL SCAN (MIN/MAX)| PK ALEX TO02 | 100K1 488K| 2 

| 5 FAST DUAL | | 1 | 2 


销 之 和 都 较 索 引 快 速 全 扫描 


小 。 我 们 可 以 把 SQL 语 句 改写 如 下 : 


min () 与 max () 通常 是 最 常 


的 高 频 SQL 写 法 之 一 ， 特 别 是 在 一 些 计 费 系统 和 报表 系统 的 应 


中 ， 这 样 的 写法 比比 皆 是 。 希 望 读 者 能 充分 利 


INDEX FULL SCAN (MIN/MAX) 这 一 蕴藏 


综 上 所 述 ， 索 引 的 扫描 和 快速 取 数 往往 是 大 家 建 索引 的 目的 ， 甚 至 有 的 时 候 会 被 认为 是 唯一 的 目的 ， 而 忽略 掉 了 索引 对 排序 的 意义 ， 
有 所 启示 ， 能 够 更 全 


面 地 了 解 和 思考 索引 的 设计 和 使 用 。 


2.3 索引 设计 优化 


CBO 优 化 器 计算 结果 的 


现在 ， 我 们 知道 了 B 树 索引 的 结构 特点 ， 也 了 解 到 其 对 查询 和 排序 优化 的 意义 ， 但 是 这 并 不 代表 我 们 就 能 建 好 有 
是 所 有 的 情况 下 索引 扫 


说 一 干道 一 万 ， 我 们 创建 索引 就 是 为 了 使 


索引 ， 尽 可 能 地 使 查询 
因素 有 很 多 ， 比 如 : 统计 信息 过 旧 、 缺 少 直方 


图 


其 间 尽 量 保证 该 列 为 NOT NULL。 


因此 丢失 了 原本 应 该 更 优 的 性 能 。 通 过 本 节 的 介绍 ， 希 望 能 对 读者 


好 索引 了 。 在 实际 工作 中 ， 是 不 是 还 是 会 遇 到 走 了 索引 反而 查询 变 慢 的 情况 呢 ? 虽然 说 不 
措 都 是 优 于 全 表 扫 描 的 ， 但 是 对 于 一 套 设 计 成 熟 的 系统 来 说， 索引 扫描 往往 是 值得 坚持 的 ， 应 该 定期 进行 全 库 SQL 语 名 


执行 计划 的 


查 ， 抓 出 全 表 扫描 的 SQL 进行 优化 。 


本 节 仍 然 沿袭 概念 结合 实例 的 方式 ， 首 先 ， 给 读者 介绍 索引 选择 度 、 索 引 聚 簇 


情况 。 


2.3.1 


的 。 


索引 选择 度 


在 这 里 ， 我 们 先 抛 出 一 个 问题 : 什么 


时 候 需要 


Ea 
FD. 


众所周知 ， 索引 发 挥 出 较 高 的 使 


效率 , 风 


:索引 理想 选择 度 =1/ 索 引 列 的 DISTINCT 数 ; 


“ 索引 实际 选择 度 = 返 回 结果 集 行 数 /全 表 行 数 。 


因子 的 概念 ; F 


操作 能 够 走 索 引 。 但 是 ， 很 遗憾 ， 不 是 我 们 说 走 索引 就 能 走 索 引 ， 还 是 需要 取决 于 CBO 优 化 器 的 成 本 计算 和 比较 情况 。 这 其 


信息 、 数 据 分 布 影响 索引 选择 度 、 索 引 聚 簇 因子 偏差 ， 等 等 。 


辅 以 数据 分 布 和 数据 存储 的 变化 对 索引 使 


索引 呢 ? 有 些 人 会 说 选择 度 20% 以 下 ， 有 些 人 会 阅 10% 以 下 ， 这 样 的 回答 都 不 尽 然 ， 甚 至 可 以 说 是 不 负责 的 。 我 们 还 是 需 


在 通过 索引 进行 查询 的 时 候 ， 其 选择 度 需 


控制 在 一 个 较 小 的 范 


通常 情况 下 ， 我 们 所 说 的 索引 选择 度 就 是 上 面 所 说 的 实际 选择 度 。 那 么 理想 选择 度 是 怎么 来 的 呢 ? 


我 们 知 


围 


全 时 5 
会 影响 


我 们 要 用 好 索引 ， 就 必须 要 充分 地 了 解 这 些 特性 和 影响 因素 。 


的 影响 ; 最 后 ， 再 分 析 实 际 工作 中 的 一 些 常见 的 索引 被 无 视 的 


根据 具体 情况 来 具体 分 析 


内 。 但 是 ， 也 需要 考虑 数据 的 实际 分 布 情况 。 这 里 我 们 引入 两 个 概念 : 


道 当 一 个 表 的 NUM_DISTINCT 值 越 接近 NUM_ROWSs 值 ， 则 优化 器 越 倾向 于 走 索引 扫描 。 那 么 最 优 情况 是 NUM_DISTINCT= NUM_ROWS (典型 代表 为 唯一 索引 ， 此 类 索引 为 理想 状态 索引 ， 


扫描 效率 最 高 ) ， 最 差 情 况 则 是 NUM_DISTINCT=1 (不 考虑 空 表 和 Null 值 ) 。 引 进 一 个 比例 NUM_ROWSVNUM_DISTINCT 来 表示 其 关联 性 ， 该 比例 的 值 越 小 则 越 优 。 通 过 一 般 情况 与 最 差 情 况 的 对 比 ， 
可 以 得 到 一 般 情况 下 的 选择 度 ， 这 个 选择 度 就 是 一 般 情况 的 理想 选择 度 。 


理想 选择 度 == (NUM_ROWSVNUM DISTINCT) / (NUM_ROWS/1) 二 1/NUM DISTINCT 


可 以 说 理想 选择 度 反 映 了 优化 器 选择 的 倾向 性 。 换 而 言 之 ， 如 果 希 望 优化 器 尽 可 能 地 选择 索引 扫描 ， 则 索引 设计 上 尽 可 能 地 参考 理想 选择 度 的 原则 ， 它 给 索引 设计 提供 一 定 的 指导 意义 。 


至 于 NUM_ROWS 和 NUM_DISTINCT 的 值 可 以 通过 扫描 表 获 取 ， 也 可 以 通过 如 下 方式 查询 数据 字典 获取 (必须 收集 统计 信息 ) : 


SQL> select num rows from dba tables; 
SQL> select num distinct from dba tab cols; 


细心 的 读者 读 到 这 里 应 该 已 经 察觉 到 了 ， 我 们 这 里 说 的 理想 选择 度 其 实 就 是 执行 计划 中 “ 集 势 ” (Cardinality) 的 一 个 重要 因子 。 集 势 因 子 是 CBO 优 化 器 COST 成 本 计算 的 重要 标准 ， 可 以 说 它 反映 了 


优化 器 的 计算 方式 ， 也 是 决定 是 否 走 索引 的 关键 因素 。 


索引 列 的 集 势 因子 如 表 2-3 所 列 : 


表 2-3 索引 列 集 势 因子 


查询 条 件 索引 列 集 势 因子 
到 1/NUM DISTINCT 


<、>、<=、>= 1/NUM DISTINCT+1/NUM ROWS 
IN NUM VARIABLE* (1/NUM DISTINCT) 
<> 1-1/NUM DISTINCT 
NOT IN (1-1/NUM DISTINCT) ^ NUM VARIABLE 
从 集 势 因子 来 看 ， 不 难看 出 “<>” 和 “NOT IN” 的 情况 比较 难以 高 效 使 用 索引 。 而 对 “=”，“<、>、< =、> =” 和 “IN” 的 情况 ， 基 本 上 都 可 以 由 1/NUM_DISTINCT 决 定 ， 也 可 以 说 它们 最 


小 公约 数 单元 就 是 等 值 查询 。 这 个 因子 ， 也 就 是 我 们 所 说 的 理想 选择 度 ， 基 本 上 可 以 反映 索引 列 各 种 高 效 查 询 的 优化 器 成 本 计算 情况 。 


2.3.2 ”数据 分 布 的 影响 


1. 均 匀 分 布 的 情况 


当 数 据 分 布 是 完全 均匀 的 ， 则 会 发 现 理想 选择 度 和 实际 选择 度 是 相等 的 ， 也 就 是 说 理想 选择 度 是 一 种 完全 理想 化 的 数据 分 布 状 态 。 当 CBO 优 化 器 在 计算 索引 扫描 成 本 的 时 候 ， 如 果 缺 少 索 引 列 直方 图 信 
息 ， 则 会 认为 数据 是 完全 均匀 分 布 的 。 这 个 时 候 无 论 COL 的 取 值 是 多 少 ， 其 选择 度 都 是 一 样 的 ， 即 理想 选择 度 等 于 实际 选择 度 。 此 时 成 本 的 比较 上 ， 通 过 索引 扫描 再 回 表 取 数 要 远 小 于 全 表 扫 描 ， 如 图 2-8 所 
示 


数据 存储 结构 


索引 扫描 成 本 + 回 表 取 数 成 本 < 全 表 扫 描 成 本 


图 2-8 ”数据 均匀 分 布 


然而 ， 这 种 情况 基本 上 是 不 存在 的 。 如 果 索 引 列 上 的 数据 分 布 较为 均匀 ， 那 么 与 CBO 优 化 器 计算 的 结果 偏差 就 不 会 太 大 ， 反 之 ， 则 会 导致 执行 计划 跑 偏 。 所 以 ， 索 引 设计 的 另 一 原则 就 是 “ 尽 可 能 地 保 


证 索引 列 数据 分 布 均匀 一 些 ”。 


说 到 数据 的 分 布 均 匀 程 度 会 影响 索引 的 效率 ， 先 来 使 用 理想 选择 度 和 实际 选择 度 来 考察 一 个 均匀 分 布 的 例子 吧 。 具 体 步 又 和 SQL 语句 如 下 所 示 : 


步骤 1 创建 一 下 相关 的 表 和 索引 : 


SQL> create table alex t03 ( 
2 id number, = 
3 coll number, 
4 name varchar2(100) 
5 ); 
SQL> alter table alex t03 add constraint pk alex t03 
2 primary key (id) using index; 二 
SQL> create index idx alex t03 coll on alex t03 (col1) 7 


步骤 2 初始 化 数据 ， 顺 序 均匀 地 插入 10 万 行 数据 ，col1 列 NUM_DISTINCT 值 控制 为 10: 


NUM_DISTINCT 值 控制 为 10: 
SQL> declare 
seq number := 1; 
begin 
for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 100000 loop 
insert into alex t03 values (i, seq, 'alex'); 中 
if mod(i, trunc(100000 / 10)) = 0 then 
seq := seq + 1; 
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步骤 3 ”收集 一 下 表 和 索引 的 统计 信息 ， 设 置 method_opt 参 数 为 FOR ALL COLUMNS SIZE 1 ， 先 不 收集 直方 图 信息 ， 看 看 数据 分 布 对 索引 选择 的 影响 。 


SQL> exec dbms stats.gather table stats('alex', "alex t03', 
method opt=>'FOR ALL COLUMNS SIZE 17) 
SQL> exec dbms stats.gather index stats('alex', 'pk alex t03') 
SQL> exec dbms stats.gather index stats('alex', 'idx alex t03 coll') 


此 时 ， 可 以 看 到 索引 列 col1 上 的 数据 分 布 是 完全 均匀 的 。 所 以 ， 不 论 是 col1=1， 还 是 col1=5 的 情况 ， 都 是 能 够 很 好 地 利用 索引 扫描 的 。 理 想 选 择 度 和 实际 选择 度 均 为 10%， 即 优化 器 计算 的 选择 度 和 实 
际 情况 是 完全 相符 的 。 示 例如 下 所 示 : 


SQL> select * from alex t03 where coll=1; 
SQL> select * from alex t03 where coll=5; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 

| 0 | SELECT STATEMENT | | 10118 | 118K| 54 (0) | 

| 1 | TABLE ACCESS BY INDEX ROWID| ALEX T03 10118°1 118K| 54 (0) | 

| 二 至 | INDEX RANGE SCAN | IDX ALEX T03 COL1 | 10118 | | 28 (0) | 
2. 非 均匀 分 布 的 情况 


如 果 说 在 索引 列 上 的 数据 分 布 不 是 均匀 的 呢 ? 如 图 2-9 所 示 ， 来 看 一 个 比较 极端 的 例子 。COL=2 的 行 数 占 总 行 数 的 60%， 那 么 查询 COL=2 的 时 候 ， 实 际 选 择 度 则 为 60%， 然 而 CO 为 其 他 值 的 实际 选择 
度 仅 为 10%。 如 果 按照 实际 选择 度 来 走 的 话 ，COL=2 走 全 表 扫描 ， 其 他 情况 走 索引 扫描 是 一 个 比较 理想 的 选择 。 


数据 存储 结构 OO 


10% 60% 10% 


AN 
索引 扫描 成 本 + 回 表 取 数 成 本 > 全 表 扫 描 成 本 


图 2-9 ”数据 不 均匀 分 布 


但 是 ， 优 化 器 的 实际 处 理 情 况 未 必 如 此 。 这 个 时 候 ， 如 果 我 们 没有 COL 列 上 的 直方 图 ， 优 化 器 会 认为 数据 是 均匀 分 布 的 ， 则 理想 选择 度 =1/NUM_DISTINCT=20%， 很 有 可 能 都 走 了 全 表 扫 描 。 这 对 了 
COL 不 为 2 的 情况 几乎 是 不 能 接受 的 。 


这 种 情况 相信 在 很 多 应 用 中 都 是 存在 的 ， 只 是 有 可 能 不 会 表现 得 这 么 极端 而 已 。 直 方 图 的 收集 对 于 大 表 来 说， 是 不 可 想象 的 ， 因 为 收集 一 次 开销 太 大 ， 对 高 并 发 的 OLTP 系 统 几 乎 是 不 可 能 完成 的 任务 。 
那 如 何 去 解 决 这 个 问题 呢 ? 这 又 将 说 回 到 索引 设计 的 话题 上 来 。 对 于 这 种 数据 分 布 极度 倾斜 的 情况 就 不 应 该 建 索引 ， 如 果 不 得 不 建 的 话 ， 尽 可 能 收集 直方 图 。 


网 


回 到 前 面 的 例子 ， 接 下 来 我 们 人 为 来 制造 一 些 麻烦 吧 ， 打 乱 原 有 的 均匀 分 布 。 如 下 例 所 示 ， 可 以 看 到 ，col1=5 的 记录 行 已 经 占 了 全 表 记 录 总 数 的 50%，col1 索 引 列 已 经 严重 倾斜 。 但 是 ， 抛 开 col1=5 的 
情况 ， 其 他 几 种 情况 ， 都 还 是 有 比较 好 的 选择 度 的 。 


SQL> update alex t03 set coll=5 where coll between 4 and 8; 

SQL> commit; 

SQL> select coll,count (coll) from alex 七 03 group by coll; 
COL1 COUNT (COL1) 加 


表 经 过 了 大 批量 的 DML 操 作 ， 统 计 信息 已 经 过 | 日 了 。 如 果 仍 采用 | 上 日 的 统计 信息 ， 上 面 基于 col1 的 查询 ,仍然 都 将 继续 索引 扫描 的 方式 ， 这 对 于 col1=5 来 说 ， 就 不 是 最 优 的 了 。 


此 时 ， 需 要 重新 收集 一 次 表 和 索引 的 统计 信息 ， 仍 然 选择 不 收集 直方 图 。 因 为 没有 直方 图 信息 ， 优 化 器 将 无 视 数据 分 布 的 倾斜 。 下 面 的 例子 中 ，col1=1 和 col1=5 的 情况 ， 都 走 了 全 表 扫 描 ， 显 然 这 个 结 
果 也 是 不 能 让 人 满意 的 。 


SQL> select * from alex t03 where coll=1; 
SQL> select * from alex t03 where coll=5; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 17406 | 203KI 85 {3)'] 
I* 1 | TABLE ACCESS FULL| ALEX T03 | 17406 | 203K| 85 (3) | 


利用 理想 选择 度 和 实际 选择 度 来 分 析 一 下 吧 。 数 据 分 布 倾斜 后 ，col1= 5 的 实际 选择 度 变 为 50%， 其 他 情况 仍 为 109%。 但 是 没有 直方 图 信息 ， 优 化 器 意识 不 到 这 一 点 ， 它 会 认为 理想 选择 度 是 从 10% 变 为 
了 16.7%， 都 应 该 走 全 表 扫 描 了 。 


换个 角度 来 思考 一 下 ， 如 果 我 们 没有 idx_alex_t03_col1 这 个 索引 ， 情 况 会 如 何 呢 ? 当然 也 将 是 全 部 走 全 表 扫 描 的 。 那 不 得 不 反问 一 句 ，idx_alex_t03_col1 这 个 索引 还 有 存在 的 意义 吗 ? 


要 让 idx_alex_t03_col1 索 引 有 存在 的 意义 ， 就 需要 依赖 于 col1 列 上 的 直方 图 信息 收集 。 我 们 重新 收集 一 下 统计 信息 和 直方 图 吧 ， 示 例如 下 所 示 : 


SQL> exec dbms_ stats.gather table stats('alex', 'alex t03', 
method opt=>'FOR ALL COLUMNS SIZE AUTO') 
SQL> exec dbms stats.gather index stats('alex', 'pk alex t03') 
SOL> exec dbms_stats.gather index stats('alex', 'idx alex t03 col1') 


再 来 对 比 一 下 col1=1 和 col1=5 查 询 的 执行 计划 看 看 ， 我 们 神奇 地 发 现 了 两 种 截然 不 同 的 情况 ， 而 且 都 是 最 优 的 。 
SQL> select * from alex t03 where coll=1; 
Id Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 SELECT STATEMENT 上 | 9873 | 115K| SS (0) | 
| 1 TABLE ACCESS BY INDEX ROWID| ALEX T03 | 9873 | 115K| 55 (0) | 
| 二 这 INDEX RANGE SCAN | IDX ALEX TO3 COL1 | 9902 | | 30 (0) | 
SQL> select * from alex t03 where coll=5; 
| 过 Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 SELECT STATEMENT | | 17406 | 203K| 85 (3) | 
上 起 TABLE ACCESS FULL| ALEX T03 | 17406 | 203K| 85 (3) | 


说 到 这 里 ， 有 人 可 能 会 提出 质疑 : “Oracle 119 提 供 的 自 适应 游标 共享 (ACS) 不 是 就 可 以 根据 不 同 的 绑 定 变量 生成 不 同 的 执行 计划 吗 ? ”这 真 的 是 一 个 不 错 的 主意 ， 但 也 仅仅 是 不 错 而 已 。 


我 们 不 要 忘 了 使 用 绑 定 变量 的 时 候 ，Oracle 有 一 个 绑 定 变量 寅 探 的 机 制 ，SQL 语 句 第 一 次 执行 决定 了 以 后 同样 的 SQL 语句 的 执行 计划 。 如 果 在 缺失 直方 图 信息 的 情况 下 ， 其 结果 和 不 绑 定 变量 的 情况 是 
一 样 的 。 如 果 很 幸运 地 拥有 直方 图 信息 呢 ? 我 们 第 一 次 执行 的 col1= : VID 绑 定 变量 : VID: =1， 则 会 走 索引 扫描 ， 第 二 次 : VID: =5 也 将 继续 索引 扫描 。 反 过 来 的 话 ， 先 执行 : VID: =5， 再 执行 : VID: 
=1， 则 都 会 走 全 表 扫 描 。 这 对 我 们 来 说 是 没有 什么 帮助 的 。 即 使 Oracle 11g 通 过 自 适应 游标 共享 进行 了 优化 ， 但 对 数据 分 布 倾斜 也 将 是 力不从心 的 。 


细心 的 读者 可 能 已 经 注意 到 了 ， 上 面 我 们 说 的 两 个 例子 ， 是 很 极端 化 的 例子 ， 一 个 过 分 均匀 ， 一 个 过 分 倾斜 ， 在 实际 应 用 中 ， 我 们 还 是 需要 中 庸 一 点 的 。 在 索引 设计 和 使 用 的 时 候 ， 需 要 关注 以 下 几 


“ 需要 像 优化 器 一 样 去 思考 ， 尽 可 能 地 参考 理想 选择 度 的 原则 ; 


“ 尽 可 能 保证 索引 列 数据 分 布 均匀 ， 否 则 不 要 建 索引 ; 


“ 如 果 不 得 不 对 数据 分 布 严 重 倾斜 的 列 建 索引 ， 请 收集 直方 图 信息 ， 同 时 关注 绑 定 变量 窥探 的 影响 。 


2.3.3 ”索引 聚 簇 因子 


再 次 回 到 上 一 节 抛 出 的 问题 ， 什 么 时 候 应 该 用 索引 ? 前 面 我 们 分 析 过 了 索引 选择 度 和 数据 分 布 的 问题 ， 而 另 一 个 会 影响 索引 使 用 的 关键 因素 就 是 索引 聚 簇 因子 (INDEX CLUSTERING FACTOR) 。 


什么 是 索引 聚 复 因 子 呢 ? 索引 聚 篮 因 子 是 指 按照 索引 列 值 进行 了 排序 的 索引 条 目 顺 序 和 其 对 应 表 中 数据 行 顺序 的 相似 程度 。 比 较 理想 的 状况 就 好 比 一 对 双胞胎 ， 其 相似 程度 是 非常 大 的 ， 此 时 索引 使 
是 非常 高 效 的 。 在 Oracle 中 ， 聚 复 因 子 大 小 对 数据 读 取 效 率 有 着 直接 的 影响 ， 聚 复 因 子 值 越 小 ， 则 说 明 相 似 程度 越 大 ， 索 引 使 用 将 越 趋 于 高 效 。 


聚 篮 因 子 是 如 何 影响 索引 的 使 用 性 能 的 呢 ? 主要 从 MO 开销 这 个 角度 来 思考 。 如 图 2-10 所 示 ， 我 们 先 来 对 比 一 下 左右 两 种 情况 的 聚 艇 因子 。 我 们 假设 一 个 表 中 只 有 三 个 数据 块 (Data Block) ， 每 个 数 
据 块 只 能 存储 三 行 数据 ， 共 需 存 储 9 行 记录 。 现 有 一 个 索引 列 ，9 行 记录 对 应 索引 列 值 为 123123123， 在 索引 结构 中 对 键 值 是 有 序 排列 的 ， 那 索引 条 目 存 储 的 顺序 应 该 为 111222333。 右 图 中 ， 表 中 数据 存储 
的 顺序 也 是 111222333， 和 索引 顺序 是 一 致 的 ; 左 图 中 表 和 索引 存储 的 结构 则 是 大 相 径 庭 的 。 按 照 聚 复 因 子 的 定义 ， 左 图 可 以 视 为 较 差 (或 者 较 大 ) 的 聚 簇 因子 ， 右 图 可 以 视 为 较 好 (或 者 较 小 ) 的 聚 簇 因 
Ts 


数据 入 表 顺 序 


数据 存储 结构 


索引 扫描 


coO]=1] 


2-10 ”索引 聚 比 因子 1/O 影 响 


当 进 行 索引 扫描 的 时 候 ， 其 实 左 右 图 并 无 什么 区 别 ， 因 为 索引 都 是 有 序 的 ， 但 是 在 回 表 取 数 的 时 候 ， 右 图 的 /O 开 销 明 显 小 于 左 图 的 。 现 在 假设 每 次 VO 只 能 读 取 一 个 数据 块 ， 那 么 当 查询 COL= 1 的 时 
候 ， 右 图 只 需 一 次 VO， 左 图 需要 三 次 ，MO 上 的 优势 立 现 。 优 化 器 在 COST 计 算 的 时 候 ， 对 于 左 图 的 情况 甚至 会 选择 全 表 扫描 ， 而 放弃 走 索 引 。 


为 什么 会 造成 表 存储 结构 和 索引 存储 结构 不 一 致 呢 ? 索引 结构 的 存储 已 经 是 有 序 排序 了 ， 所 以 不 一 致 的 问题 出 在 表 的 存储 上 。 我 们 通常 所 说 的 表 都 是 堆 表 ， 其 最 大 特征 就 是 数据 存储 的 独立 性 ， 数 据 的 
存储 和 数值 本 身 没有 任何 关系 ， 是 随机 存储 在 任意 位 置 上 的 ， 即 随机 存储 在 任意 的 数据 块 上 。 


很 幸运 的 是 ，Oracle 提 供 了 索引 的 聚 艇 因子 ， 可 以 通过 数据 字典 查询 到 相关 索引 的 聚 篮 因 子 信息 ， 如 下 : 


SQL> select index name, clustering factor 
2 from dba indexes where table name='ALEX T03'; 


INDEX_ NAME CLUSTERING FACTOR 
PK ALEX T03 247 
IDX ALEX TO3 COL1 251 


简单 来 说 ，CLUSTERING_FACTOR 反 映 的 是 通过 索引 扫描 访问 一 张 表 ， 需 要 访问 的 表 的 数据 块 数量 ， 即 反映 |/O 的 次 数 。 这 个 CLUSTERING_FACTOR 是 如 何 计 算出 来 的 呢 ? 
1) 扫描 索引 结构 ; 


2) 顺序 对 比 相 邻 索引 条 目的 ROWID， 如 果 两 个 ROWID 属 于 不 同 数据 块 ， 那 么 CLUSTERING_FACTOR 增 加 1; 


3) 整个 索引 扫描 结束 后 ， 就 可 以 得 到 该 索引 的 聚 簇 因子 数值 。 


了 解 了 CLUSTERING_FACTOR 的 计算 方法 ， 我 们 可 以 得 出 以 下 两 个 极端 的 情况 ， 即 聚 复 因 子 最 大 和 最 小 的 情况 : 


“ CLUSTERING_FACTOR 最 小 时 ， 其 无 限 接近 于 表 的 数据 块 数 ， 该 表 是 按照 索引 字段 顺序 存储 的 ; 
“ CLUSTERING_FACTOR 最 大 时 ， 其 无 限 接近 于 表 的 行 数 ， 该 表 是 完全 不 按照 索引 字段 顺序 存储 的 。 
ia 结合 聚 簇 因子 和 选择 度 ， 基 本 上 就 可 以 确定 索引 扫描 的 COST 开 销 了 。 

2.3.4 数据 存储 的 影响 


1. 聚 簇 因子 较 好 的 情况 


接 下 来 通过 一 个 实例 来 验证 一 下 聚 伐 因子 对 索引 性 能 的 影响 吧 。 先 考察 聚 篮 因 子 较 好 的 情况 ， 此 时 CLUSTERING_FACTOR 的 数值 将 会 比较 小 。 下 面 例子 中 ， 我 们 按照 前 面 提 到 的 “111222333” 的 方式 
进行 数据 入 库 。 


步骤 1 清空 表 alex_t03 的 数据 : 


SQL> truncate table alex t03; 


步骤 2 按照 “11122233” 的 方式 重新 插入 10 万 行 数据 ，NUM_DISTINCT 值 控制 为 200: 


SQL> declare 
2 seq number := 1; 
3 begin 
4 for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 100000 loop 


三 insert into alex t03 values (i, seq, 'alex'); 
6 if mod(i, trunc(1T00000 / 200)) = 0 then 

7 seq := seq + 1; 

8 end if; 

9 end loop; 

10 commit; 

11 end; 

1a 六 


步骤 3 ”重新 收集 一 下 表 和 索引 的 统计 信息 ， 这 里 不 关注 直方 图 信息 : 


SQL> exec dbms_stats.gather table stats('alex', "alex t03') 
SQL> exec dbms_ stats.gather index stats('alex', "pk alex t03') 
SQL> exec dbms_ stats.gather index stats('alex', 'idx alex t03 coll') 


IDX 


主键 列 的 数据 入 库 是 完全 有 序 的 ， 可 以 将 主键 索引 视 为 一 个 理想 的 聚 艇 因子 情况 ， 将 col1 列 的 索引 聚 复 因 子 与 之 对 比 一 下 ， 可 以 发 现 CLUSTERING_FACTOR 数 值 上 是 差不多 的 ， 索 引 


ALEX_T03_COL1 的 聚 簇 因子 比较 好 ， 远 小 于 数据 行 数 ， 接 近 数 据 块 数 。 统 计 结果 如 下 所 示 : 


SQL> select i.index name, t.blocks, t.num rows, i.clustering factor 
2 from user tables t, user indexes i 
3 where t.table name=i.table name and i.table name='ALEX T03'; 


INDEX_NRME BLOCKS “NUM ROWS CLUSTERING FACTOR 
PK ALEX T03 370 102127 254 
IDX ALEX TO3 COLL 370 102127 324 


当 进 行 col1 索 引 列 的 查询 的 时 候 ， 妇 庸 置疑 的 是 进行 索引 扫描 了 ， 而 且 COST 开 销 相对 较 小 ， 也 就 是 说 索引 利用 比较 高 效 。 示 例如 下 所 示 : 


SQL> select * from alex t03 where coll=1; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 655 | 8515 | 5 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX T03 | 655 | 8515 | 5 (0) | 
位 : 次 INDEX RANGE SCAN | IDX ALEX T03 COL1 | 655 | | 2 (0) | 
Statistics 


0 db block gets 
173 consistent gets 
29 physical reads 
16 sorts (memory) 

0 sorts (disk) 
500 ows processed 


2. 聚 艇 因子 较 差 的 情况 


如 果 按照 “123123123” 的 方式 进行 数据 入 库 是 不 是 会 出 现 另 一 个 极端 的 情况 呢 ” 同样 通过 一 个 例子 来 看 一 下 吧 ， 仍 然 使 用 alex_t03 表 ， 仅 仅 改变 数据 入 库 顺 序 。 


步骤 1 清空 alex_t03 的 数据 : 


SQL> truncate table alex t03; 


步骤 2 按照 “123123123” 的 方式 重新 插入 10 万 行 数据 ，NUM_DISTINCT 值 控制 为 200: 


SQL> declare 
2 seq number := 1; 


3 begin 

4 for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 100000 loop 
号 insert into alex t03 values (i, seq, 'alex'); 2 

6 if mod(i, trunc(100000 / 200)) = 0 then 

seq := seq + 17 

8 end if; 

9 end loop; 

10 commit; 

11 end; 

12 / 


步骤 3 ”重新 收集 一 下 表 和 索引 的 统计 信息 ， 这 里 不 关注 直方 图 信息 : 


SQL> exec dbms_stats.gather table stats('alex', "alex t03') 
SQL> exec dbms stats.gather index stats('alex', "pk alex t03') 
SQL> exec dbms_ stats.gather index stats('alex', 'idx alex t03 coll') 


加 


子 的 情况 。 统 计 结果 如 下 所 示 : 


如 预料 的 一 样 ，CLUSTERING_FACTOR 变 得 很 大 ， 远 远大 于 数据 块 数 ， 更 趋 于 接近 数据 行 数 ， 显 示 这 是 一 个 比较 差 的 聚 簇 | 


SQL> select i.index name, t.blocks, t.num rows, i.clustering factor 
2 from user tables t, user indexes i 
3 where t.table name=i.table name and i.table name='ALEX T03'; 


INDEX_NAME BLOCKS NUM ROWS CLUSTERING FACTOR 
PK RATLEX_ TO03 370 102127 254 
IDX ALEX T03_COL1 370 102127 50759 


再 进行 一 次 同样 的 查询 操作 ， 发 现 优化 器 放弃 了 索引 扫描 而 进行 了 全 表 扫 描 ， 这 意味 着 此 时 全 表 扫 描 的 开销 更 小 。 从 下 例 的 统计 信息 看 到 ， 全 表 扫 描 的 物理 读 和 逻辑 读 都 比较 好 聚 篮 因 子 的 情况 要 大 得 
甚至 出 现 了 16 次 额外 的 内 存 排序 操作 。 


SQL> select * from alex t03 where coll=1; 


673 | 8749 | 85 全 | 
673 | 8749 | 85 (3) 1 


0 db block gets 
433 consistent gets 
302 physical reads 

16 sorts (memory) 

0 sorts (disk) 
500 rows processed 


即便 如 此 ， 优 化 器 仍 认为 全 表 扫描 更 优 ， 那 强制 走 一 下 索引 扫描 看 看 情况 如 何 呢 》 如 下 例 所 示 ， 比 较 索 引 扫描 和 全 表 扫 描 的 统计 信息 似乎 相差 无 几 ， 但 是 COST 开 销 、 索 引 扫描 大 了 很 多 。 


SQL> select /*+index (alex t03 idx alex 七 03_col1)*/ 大 
2 from alex t03 where coll=1; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 673 | 8749 | 344 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX T03 | 673 | 8749 | 344 (0) | 
[| INDEX RANGE SCAN | IDX ALEX TO3 COL1 | 673 | | 疙 (0) | 


0 db block gets 
409 consistent gets 
274 physical reads 

16 sorts (memory) 

0 sorts (disky 

500 rows processed 


此 时 ， 如 果 再 对 比 聚 簇 因子 较 好 和 较 差 两 种 情况 下 的 索引 扫描 情况 ， 很 容易 就 验证 了 我 们 之 前 的 说 法 ， 较 好 的 聚 簇 因子 会 带 来 较 大 的 1/O 优 势 。 


在 实际 应 用 中 ， 表 中 数据 的 入 库 有 一 定 的 随机 性 ， 其 顺序 是 我 们 无 法 控制 的 ， 这 意味 着 索引 的 聚 篮 因 子 也 很 难得 到 控制 。 这 对 我 们 在 索引 设计 上 也 是 一 个 较 大 的 挑战 ， 在 新 建 索引 之 前 ， 应 该 尽 可 能 地 
了 解 业务 数据 的 存储 特性 ， 保 证 数据 存储 顺序 有 一 定 的 规律 ， 即 拥有 较 小 的 聚 艇 因子 ， 索 引 才 能 高 效 使 用 。 如 果 不 能 保证 较 小 聚 艇 因子 ， 要 想 通过 后 期 的 维护 来 修正 ， 那 基本 上 是 不 可 能 实现 的 。 


综合 以 上 内 容 ， 我 们 可 以 来 总 结 一 下 了 ， 一 个 设计 优秀 的 索引 应 该 具有 以 下 特点 : 
“ 具有 较 好 的 选择 度 ， 能 参考 理想 选择 度 来 界定 ; 

-索引 列 的 数据 分 布 足够 趋 于 均匀 化 ; 

" 具有 较 小 的 桑 付 因子 。 


@ia 示 当 不 知道 如 何 把 握 的 时 候 ， 可 以 参考 一 下 唯一 索引 ， 其 从 各 方面 来 思考 都 是 最 高 效 的 ， 尽 可 能 地 使 你 的 索引 接近 于 它 。 


2.3.5 ”复合 索引 


1. 复 合 索引 设计 


在 工作 中 ， 我 们 时 常会 被 问 及 一 个 问题 : “我 将 如 何 选择 索引 列 来 建立 复合 索引 呢 ? ” 举 一 个 例子 来 说 说 看 吧 。 


现在 有 一 张 表 的 三 个 列 : A、B、C， 在 日 常 的 业务 应 用 中 ， 会 用 到 两 两 组 合 的 查询 ， 即 : A and B，B and C，A and C， 将 如 何 建 复 合 索 引 呢 ?这 是 一 个 很 不 明确 的 需求 ， 我 们 很 难以 此 为 据 来 作出 判 
需要 进一步 跟 需 求 方 沟通 。 


本 


经 过 数据 量 和 数据 分 布 等 情况 的 分 析 ， 确 定 是 需要 建 索引 的 ， 问 题 将 集中 在 如 何 去 建 ， 建 什么 样 的 索引 。 
架构 师 : “这 三 种 场景 发 生 的 概率 大 致 如 何 呢 ?“ 
开发 者 : “各 占 三 分 之 一 吧 。 


架构 师 : “ 除 此 之 外 ， 还 有 这 三 个 列 上 其 他 查询 吗 ?“ 


开发 者 : “可 能 还 有 少量 的 B 列 和 C 列 的 单列 查询 吧 ， 但 是 真 的 比较 少 。” 


架构 师 : “ 那 这 三 个 列 的 数据 区 分 度 是 怎么 样 的 呢 ?“ 


开发 者 : “A 列 区 分 度 比 较 低 ，B 列 和 C 列 将 比较 高 。” 


架构 师 : “这 真 的 是 一 个 比较 棘手 的 问题 。.…… 问 题 主 要 集中 在 这 三 个 列 的 区 分 度 上 ， 如 果 A 列 很 低 ，B 和 C 很 高 的 话 ， 我 建议 可 以 考虑 不 建 复合 索引 ， 只 建 B 列 和 C 列 的 单列 索引 。” 


开发 者 : “这 是 你 的 第 一 个 建议 吗 ? 但 是 我 并 不 是 很 确定 A 列 的 区 分 度 是 否 真 的 像 预期 的 那么 小 ， 或 者 说 B 列 和 C 列 的 区 分 度 未 必 像 预 期 的 那么 大 。” 


架构 师 : “是 的 ， 如 果 用 单列 索引 就 能 解决 问题 ， 当 然 是 最 好 不 过 的 了 。 但 是 ， 从 你 的 描述 中 ， 我 对 使 用 单列 索引 还 是 有 所 担心 的 ， 我 建议 可 以 考虑 建 (B，C) 复合 索引 和 C 列 单列 索引 。 这 样 ， 
(B，C) 复合 索引 可 以 覆盖 B and C 查 询 和 A and B 查 询 ，C 列 单列 索引 可 以 覆盖 A and C 查 询 ， 因 为 A 列 区 分 度 不 高 ， 可 以 不 考虑 其 走 索引 。“ 


开发 者 : “ 那 为 什么 不 干脆 建 (B，C) ， (B，A) ， (C，A) 三 个 复合 索引 呢 ?“ 


架构 师 : “这 个 当然 很 好 了 ， 但 是 索引 维护 开销 太 大 ， 未 必 是 好 事 。 


开发 者 : “ 那 能 不 能 使 用 INDEX SKIP SCAN 的 特性 呢 ?“ 


架构 师 : “ 非 必要 时 不 要 用 ， 尽 可 能 选择 区 分 度 比较 高 的 列 作为 复合 索引 的 前 导 列 ， 这 样 前 导 列 单列 查询 的 时 候 也 能 很 好 地 使 用 复合 索引 。“ 


开发 者 : “ 那 能 不 能 建 三 个 列 的 复合 索引 呢 ?“ 


架构 师 : “能 是 能 ， 但 是 不 建议 这 么 干 。 你 这 个 表 数 据 量 比较 大 的 话 ， 你 可 以 相像 一 下 这 个 索引 结构 会 多 复杂 ， 后 期 维护 也 是 很 痛苦 的 。 


架构 师 : “好 了 ， 我 们 现在 一 共有 三 个 方案 。 第 一 ，B 列 和 C 列 的 单列 索引 ;第 二 ， (B，C) 复合 索引 和 (C 列 单列 索引 ， 第 三 ， (B, C) ， (B，A) ， (C，A) 三 个 复合 索引 。 其 中 ， 第 二 个 是 最 优 推 
荐 的 。” 


开发 者 : “好 的 ， 那 就 按照 第 二 个 来 建 吧 。” 
架构 师 : “还 不 行 。 我 们 需要 请 开发 DBA 做 一 次 影响 分 析 后 ， 再 确定 是 否 可 以 建 。” 


开发 者 : “影响 分 析 ? 怎么 做 的 呢 ?“ 


架构 师 : “就 是 对 比索 引 建立 前 后 该 表 上 所 有 SQL 语句 的 执行 计划 的 变化 情况 。 如 果 变 好 了 ， 自 然 没 有 问题 ， 如 果 变 差 了 ， 就 不 能 创建 了 。 如 果 必 须 创 建 ， 就 需要 使 用 OUTLINE 或 者 SPM 固 定 有 可 能 变 
的 执行 计划 后 ， 再 行 创建 。” 


开发 者 : “ 那 不 是 很 麻烦 吗 ? 不 这 么 干 行 不 行 呢 ?” 


架构 师 : “是 很 麻烦 ， 但 是 为 了 保证 系统 的 稳定 运行 ， 这 是 必 不 可 少 的 。 宁 愿 把 难度 做 在 设计 阶段 ， 也 不 要 把 难度 留 给 运 维 阶段 。” 


通过 上 述 的 一 段 工作 对 话 ， 我 们 大 致 可 以 了 解 到 一 些 复合 索引 设计 和 使 用 的 小 技巧 了 吧 。 其 实 ， 上 面 提 到 的 影响 分 析 ， 不 只 是 在 建 复合 索引 的 时 候 需要 做 ， 在 建 单列 索引 和 收集 统计 信息 等 有 可 能 造成 
执行 计划 变化 的 DBA 操 作 都 需要 做 。 


2. 使 用 实例 


复合 索引 的 设计 很 大 程度 上 可 以 参考 单列 索引 来 进行 ， 其 比较 大 的 一 个 特点 就 是 前 导 列 和 后 置 列 的 选择 问题 。 通 过 下 面 一 个 例子 ， 我 们 来 对 比 看 一 下 吧 。 具 体 步 骤 和 SQL 语句 如 下 所 示 : 


步骤 1 创建 一 下 相关 的 表 和 索引 : 


SQL> create table alex t04 ( 
2 id number, 


3 

4 

5 

6 es 

7 name varchar2(100) 
8 

> 


) 7 
alter table alex t04 add constraint pk alex t04 


SQ 
2 primary key (id) using index; 

SQL> create index idx alex t04 ab on alex t04 (a, b); 

SQL> create index idx alex t04 cd on alex t04 (c, qd); 


步骤 2 初始 化 数据 ， 制 造 a 列 超 低 区 分 度 ，b、c、d 三 列 较 高 区 分 度 : 


SQL> declare 

2 begin 

3 for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 100000 loop 
4 insert into alex t04 本 
号 values 
6 (i, mod(i, 2), mod(i, 20000), mod(i, 20000), 
7 mod(i, 20000), 'alex'); 
8 end loop; 
9 commit; 
0 end; 
和 


/ 


步骤 3 同样 收集 一 下 表 和 索引 的 统计 信息 : 


SQL> exec dbms stats.gather table stats 
SQL> exec dbms_ stats.gather index stats 
SQL> exec dbms stats.gather index stats 
SQL> exec dbms_ stats.gather index stats 


'alex', 'alex t04') 

'alex', 'pk alex t04') 
"alex'v 'idx alex t04 ab') 
'alex', 'idx alex t04 cd') 


对 于 查询 条 件 覆 盖 了 所 有 复合 索引 列 ， 不 论 是 低 区 分 度 的 前 导 列 还 是 高 区 分 度 的 前 导 列 ， 同 样 走 了 INDEX RANGE SCAN， 达 到 较 好 的 预期 效果 。 示 例如 下 所 示 : 


SQL> select * from alex t04 where a=1 and b=600; 


| Rows Bytes | Cost (%CPU)| 


| 0 | SELECT STATEMENT | | 3 EE 6 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX T04 | 3 5. 1 6 (0) | 
| 要 “过 INDEX RANGE SCAN | IDX ALEX T04 AB | 号 | 1 (0) 1 


| Id | Operation | Name | Rows Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 1 25 | 6 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX T04 | 让 6 (0) | 
[党 次 于 INDEX RANGE SCAN | IDX ALEX TO04 CD | 时 | 不 (0) | 


在 复合 索引 的 使 用 中 ， 查 询 条 件 覆盖 所 有 复合 索引 列 的 情况 是 最 优 的 。 如 果 在 建 索引 的 时 候 ， 能 够 充分 考虑 到 这 一 点 自然 是 最 好 的 。 就 像 前 一 节 的 场景 对 话 ， 如 果 能 创建 (B，C) ， (B，A) ， 
(C，A) 三 个 复合 索引 ， 完 全 覆盖 查询 场景 自然 是 最 优 的 选择 ， 但 是 也 不 得 不 考虑 其 运 维 代价 。 说 白 了 ， 就 是 要 用 更 少 的 、 结 构 更 简单 的 索引 来 达成 更 多 的 场景 需求 ， 实 现 索引 的 高 效 使 用 。 


对 于 复合 索引 来 说 ， 其 高 效 在 哪里 呢 ? 索引 列 全 覆盖 自然 不 用 说 ， 无 论 如 何 都 是 高 效 的 。 问 题 应 该 集中 在 前 导 列 和 后 置 列 的 使 用 上 。 众 所 周知 ， 复 合 索引 的 前 导 列 是 可 以 覆盖 其 单列 查询 的 ， 而 后 置 列 
则 未 必 ， 除 非 满足 INDEX SKIP SCAN 的 条 件 。 如 下 面 的 例子 所 示 。 


对 于 较 低 区 分 度 前 导 列 的 复合 索引 idx_alex_t04_ab 来 说 ， 当 发 生前 导 列 单列 查询 是 无 法 使 用 到 索引 的 ,或 者 说 不 使 用 索引 效率 更 高 。 


SQL> select * from alex t04 where a=1; 


| 0 | SELECT STATEMENT | | 50000 | 1220K| 115 [ 
I* 1 | TABLE ACCESS FULL| ALEX T04 | 50000 | 1220KI 115 


在 后 置 列 查询 中 ， 我 们 看 到 INDEX SKIP SCAN 的 效率 还 是 挺 高 的 。 那 是 因为 我 们 选择 的 前 导 列 a 有 极 低 的 区 分 度 ， 否 则 的 话 ， 其 效率 不 会 太 高 ， 或 者 不 使 用 索引 扫描 而 选择 全 表 扫 描 。 


SQL> select * from alex t04 where b=600; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | 5 | 5 | 8 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX T04 : 5 | 25 .| 8 (0) | 
| 二 “区 INDEX SKIP SCAN | IDX ALEX TO04 AB | | | 3 (0) 1 


可 以 这 么 说， 一 个 前 导 列 区 分 度 不 高 的 复合 索引 ， 满 足 不 了 前 导 列 单列 查询 的 需要 ， 也 未 必 能 较 好 地 满足 后 置 列 的 单列 查询 需要 。 这 样 的 复合 索引 的 使 用 效率 就 显得 不 高 了 。 


观 前 导 列 区 分 度 较 高 的 复合 索引 idx_alex_t04 cd， 前 导 列 的 单列 查询 入 庸 置疑 地 满足 了 高 效 索 引 扫描 。 如 下 所 示 : 


SQL> select * from alex t04 where c=1; 


Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
0 | SELECT STATEMENT | | 尼 | (0) | 
1 | TABLE ACCESS BY INDEX ROWID| ALEX T04 | 5 | 125 | 7 (0) | 
全 :| INDEX RANGE SCAN | IDX ALEX TO04 CD | :| 1 


对 于 后 置 列 的 单列 查询 来 说， 就 直接 说 “不 ”， 简 单干 脆 ， 便 于 把 握 ， 避 免 了 “未 必 ” 这 种 模棱两可 、 难 以 把 握 的 情况 ， 也 减少 了 后 期 出 现 问题 和 偏差 的 几率 。 如 下 所 示 : 


SQL> select * from alex t04 where d=600; 


| Id | Operation Name | Rows Bytes | Cost (SCPU) | 
| 0 | SELECT STATEMENT | 5 125 1 115 | 
Il* 1 | TABLE ACCESS FULL| ALEX T04 | . 325.| 115 5}] 


小 结 一 下 复合 索引 的 设计 和 使 用 吧 : 


“ 在 复合 索引 的 应 用 中 ， 查 询 条 件 履 盖 所 有 的 索引 列 ， 查 询 效果 最 优 ; 
“ 尽 可 能 地 用 更 少 的 、 结 构 更 简单 的 索引 来 达成 更 多 的 场景 需求 ; 


“ 一 般 来 说 ， 在 复合 索引 创建 的 时 候 ， 前 导 列 都 建议 选择 区 分 度 较 高 的 ， 故 INDEX SKIP SCAN 往 往 就 是 被 优化 对 象 。 


2.3.6 ”索引 被 无 视 


说 一 干道 一 万 ， 索 引 创 建 了 就 是 
门 展开 几 个 比较 典型 的 场景 来 讨论 一 下 


巴 。 准备 工作 具体 步骤 如 下 : 


= 


步骤 1 创建 一 下 相关 的 表 和 索引 : 


的 ， 可 偏偏 很 多 时 候 ， 索 引 被 SQL 语句 无 视 了 ， 没 有 被 用 上 ， 此 时 往往 需要 DBA 的 介入 进行 优化 。 抛 开 索引 本 身 的 问题 不 说 ， 哪 些 情况 下 索引 会 被 无 视 呢 ? 下 


岂 


SQL> create table alex t02 as 
2 select rownum id, a.* from dba objects a; 
alter table alex t02 add constraint pk alex t02 
primary key (id) using index;S 
create index idx alex t02 objid on alex t02 (object id); 
create index idx alex t02 objn on alex t02 (object name); 


SQL> 
本 


SQL> 

SQL> 

SQL> create index idx alex t02 typown on 
2 alex t02 (object type,owner); 


步骤 2 收集 一 下 表 和 索引 的 统计 信息 : 


SQL> exec dbms stats.gather table stats('alex','alex t02') 

SQL> exec dbms stats.gather index stats('alex', 'pk alex t02') 

SQL> exec dbms stats.gather index stats('alex','idx alex t02 objid') 
SQL> exec dbms_ stats.gather index stats('alex', 'idx alex t02 objn') 
SQL> exec dbms stats.gather index stats 


2 ('alex','idx alex t02 typown") 


1. 列 与 列 的 对 比 


当 进 行 单 表 查 询 的 时 候 ， 发 生 列 和 列 的 对 比 是 无 法 走 索引 的 ， 即 使 对 比 的 两 个 列 上 都 有 索引 。 这 里 ， 我 们 也 可 以 想象 一 下 ， 如 果 需 要 它 走 索引 ， 将 会 是 怎么 样 的 呢 ? pk_alex_t02 和 idx_alex_t02 objid 


两 个 索引 进行 联 立 对 比 ， 筛 选 出 等 值 的 情况 ， 这 样 的 做 法 远 不 如 进行 全 表 扫 描 来 得 高 效 了 。 示 例如 下 所 示 : 


SQL> select * from alex t02 where id=object id; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 

| 0 | SELECT STATEMENT | | 99 | 137 (3) | 

Il* 1 | TABLE ACCESS FULL| ALEX T02 | | 99 | 137 (3)1 
2. 存 在 NULL 条 件 


NULL 值 一 直 是 一 个 很 难 搞 的 东西 ， 在 查询 、 排 序 等 操作 时 经 常 制造 麻烦 。 在 表 的 设计 当中 ， 我 们 就 应 该 尽 可 能 避免 NULL 的 出 现 ， 赋 予 一 些 没有 实际 意义 的 缺 省 值 来 取代 NULL 值 。 在 索引 建立 的 时 


候 ， 我 们 很 难 去 给 NULL 建 立 合适 的 条 目 ， 进 行 NULL 值 查询 的 时 候 ， 也 将 不 大 可 能 进行 索引 扫描 。 也 就 是 说 一 个 表 的 列 值 存在 NULL 值 时 ， 该 列 的 索引 是 不 会 为 NULL 值 创建 条 目的 ， 那 么 索引 的 值 是 少 于 表 
的 值 的 ，NULL 值 的 查询 过 程 自然 就 忽略 了 索引 。 如 下 所 示 : 

SQL> select * from alex t02 where object id is not null; 

1Id4 1 operation |Name |Rows | Bytes | Cost (CPO)| 

| 0 | SELECT STATEMENT | 40729 | 3937KI 138 {3)1 

I* 1 | TABLE ACCESS FULL| ALEX T02 | 40729 | 3937K| 138 (3) | 
3.NOT 条 件 

我 们 知道 索引 会 给 每 个 索引 列 的 值 对 应 一 个 索引 条 目 ， 当 告诉 索引 选择 出 某 个 值 或 某 个 范围 的 值 时 ， 索 引 就 会 对 应 到 相应 的 索引 条 目 。 反 过 来 看 ， 当 告诉 索引 不 要 选择 某 个 值 或 某 个 范围 的 值 ， 索 引 就 


很 难 对 应 相应 条 目 了 。 


下 面 的 例子 中 ，< >、not in、not exists 的 情况 都 是 很 难 使 用 到 索引 的 : 


SQL> select * from alex t02 where object id<>500; 


I 和 Operation | Name | Rows | Bytes 
0 SELECT STATEMENT | | 40728 | 3937K 138 (3) | 
过“ 下 TABLE ACCESS FULL| ALEX T02 | 40728 | 3937K 138 (3)1 


I Operation | Name | Rows | Bytes Cost (%CPU) | 
0 SELECT STATEMENT | | 40725 | 3937K 139 (4) | 
和 站 TABLE ACCESS FULL| ALEX T02 | 40725 | 3937K 139 (4) | 


SQL> select * from alex t02 where not exists 
2 (select 1 from alex t01 where alex t02.id=alex t01.id); 


Id Operation | Name | Rows | Bytes | Cost (%CPU)| 
0 SELECT STATEMENT 1 | 23 | 2392 1 150 (11)| 
1 NESTED LOOPS ANTI | | 23 | 2392 1 150 {11)1 


| 2 1 TABLE ACCESS FULL| ALEX T02 | 40729 | 3937K| 137 (3)1 
Il* 3 | INDEX UNIQUE SCAN| PK RATEX TO1 | 99944 | 488K| 0 (0)1 
4.LIKE 前 置 通 配 符 


当 使 用 LIKE 进 行 模糊 查询 的 时 候 ， 我 们 一 般 推 荐 使 用 后 置 的 通配符 ， 这 样 可 以 较 好 地 利用 索引 扫描 ， 较 为 高 效 。 示 例如 下 所 示 : 


SQL> select * from alex t02 where object name like 'ALL%'; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 2 | 198 | 3 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX TO2 | 2 | 198 | 3 (0) | 
位 :次 INDEX RANGE SCAN | IDX ALEX T02_OBJUN | 2 1 | 2 (0) | 


但 是 实际 使 用 中 ， 很 多 时 候 是 我 们 不 得 不 使 用 前 置 通配符 ， 这 样 的 操作 是 无 法 使 用 索引 的 。 为 什么 呢 ? 我 们 试想 一 下 ， 如 果 进 行 索引 扫描 的 话 ， 索 引 结构 是 有 序 的 ， 模 糊 的 前 置 很 可 能 要 扫描 绝 大 部 分 
或 全 部 的 索引 块 ， 再 回 表 取 数 时 ， 也 很 有 可 能 扫描 绝 大 部 分 的 数据 块 ， 这 样 的 COST 开 销 是 非常 大 的 ， 优 化 器 宁愿 选择 直接 进行 全 表 扫 描 ， 实 际 COST 开 销 会 更 节省 一 些 。 所 以 ， 前 置 通配符 的 模糊 查询 是 不 
能 走 索引 的 。 


SQL> select * from alex t02 where object name like '%ALL'; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 2036 | 196K| 137 (3) | 
Il* 1 | TABLE ACCESS FULL| ALEX T02 | 2036 | 196K| 137 (3)1 


业务 系统 设计 的 时 候 ， 尽 可 能 地 考虑 到 模糊 查询 ， 避 免 使 用 低 效 的 前 置 通 配 符 ， 而 更 多 地 使 用 能 走 索引 的 较 高 效 的 后 置 通配符 。 


5. 条 件 列 上 使 用 函数 


在 下 面 的 例子 中 ， 在 索引 列 上 使 用 了 函数 ， 这 同样 是 无 法 使 用 索引 的 。 在 实际 应 用 中 ， 尽 可 能 地 使 用 第 二 种 方式 ， 在 变量 上 使 用 函数 转换 后 ， 再 与 索引 列 进行 对 比 。 当 不 得 不 在 索引 列 上 使 用 函数 的 时 
候 ， 就 必须 在 该 列 上 创建 函数 索引 。 但 是 ， 函 数 索 引 不 是 一 个 很 高 效 的 东西 ， 应 尽量 避免 使 用 或 者 少 用 。 示 例如 下 所 示 : 


SQL> select * from alex t02 where 
2 upper(object name)="'ALL RULE SET RULES'; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | |! 407 | 40293 | 137 (3) | 
Il* 1 | TABLE ACCESS FULL| ALEX T02 | 407 | 40293 | 137 (3) | 


SQL> select * from alex t02 where 
2 object name=upper('ALL RULE SET RULES ') 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 2 | 198 | 2 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX T02 | 县 中 198 | 2 (0) | 
优生 二 INDEX RANGE SCAN | IDX ALEX TO02 OBJN | 21 | (0) | 


说 到 此 处 ， 数 据 类 型 隐 式 转换 的 问题 是 不 得 不 提 的 。 隐 式 转换 实质 上 也 是 一 种 函数 转换 的 操作 ， 只 不 过 是 没有 明确 写 明 函数 ， 由 Oracle 自 动 完成 的 。 如 下 面 的 例子 ，id 列 是 NUMBER 型 的 ， 如 果 查 询 
id='12345'，Oracle 会 自动 转换 为 jd=12345 后 ， 再 进行 查询 ， 转 换 的 过 程 实质 上 就 是 做 了 一 次 to_number 函 数 的 转换 操作 。 这 样 同样 是 无 法 进行 索引 扫描 的 。 SQL 语句 如 下 : 


SQL> select * from alex t02 where id = '12345'; 
SQL> select * from alex t02 where id = to number('12345"'); 


在 实际 应 用 中 ， 数 据 类 型 隐 式 转换 是 需要 尽量 避免 的 ， 隐 式 转换 不 但 不 能 进行 索引 扫描 ， 而 且 会 影响 绑 定 变量 的 使 用 。 


6. 高 区 分 度 前 导 列 的 复合 索引 后 置 列 查 询 


高 区 分 度 前 导 列 的 复合 索引 无 法 用 于 后 置 列 查询 ， 这 个 例子 其 实 前 面 的 章节 已 经 讨论 过 了 。 如 果 前 导 列 区 分 度 很 低 ， 可 以 走 INDEX SKIP SCAN， 如 果 前 导 列 区 分 度 高 的 话 ， 进 行 INDEX SKIP SCAN 时 
分 裂 逻 辑 子 索引 开销 将 非常 大 ， 不 如 直接 走 全 表 扫 描 。 示 例如 下 : 


SQL> select * from alex t02 where owner='ALEX'; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | 1 3133 1 302K| 136 | 
Il* 1 | TABLE ACCESS FULL| ALEX T02 | 3133 | 302K| 136 (2) | 


2.4 索引 分 裂 


通过 前 面 三 节 的 介绍 ， 相 信 各 位 读者 已 经 能 对 索引 的 设计 及 其 影响 因素 有 了 一 定 的 把 握 ， 接 下 来 两 节 我 们 将 进行 到 索引 新 建 后 的 维护 阶段 。 先 想 一 想 ， 索 引 为 什么 需要 维护 ?因为 它 不 能 保证 高 效 的 查 
询 和 DML 操 作 ， 甚 至 成 了 一 种 拖累 ， 或 者 大 家 都 很 “喜欢 ” 它 ， 它 有 些 不 堪 重 负 了 。 这 些 问题 对 我 们 来 说 都 是 不 能 置之不理 的 ， 否 则 宁可 不 建 索引 。 


知 其 然 必 知 其 所 以 然 ， 要 想 解决 索引 的 问题 ， 需 要 先知 道 这 些 问题 是 怎么 产生 的 。 我 们 知道 B 树 索引 的 结构 就 像 一 棵 树 一 样 ， 这 棵 树 随 着 业务 数据 的 增加 ， 也 是 会 慢 慢 生 长 起 来 的 ， 自 然 也 有 了 其 “成 长 
的 烦恼 ”。 那 这 棵 树 是 通过 什么 方式 来 生长 的 呢 ” 这 也 是 问题 的 关键 ， 也 是 我 们 接 下 来 要 展开 讨论 的 话题 一 一 索引 分 裂 。 


本 节 将 深入 剖析 索引 树 分 裂 生 长 原理 ， 各 种 分 裂 的 形式 ， 以 及 因此 带 来 的 问题 和 解决 的 方法 。 
2.4.1 分 裂 原 
1. 什 么 是 分 裂 


在 开始 介绍 之 前 ， 我 们 先 来 搞 清楚 什么 是 索引 分 裂 吧 。 “索引 分 裂 ” 就 是 索引 块 的 分 裂 ， 当 一 次 DML 事 务 操作 修改 了 索引 块 上 的 数据 ， 但 是 | 日 有 的 索引 块 没有 足够 的 空间 来 容纳 新 修改 的 数据 ， 那 么 将 


分 裂 出 一 个 新 索引 块 ， 旧 有 块 的 部 分 数据 放 到 新 开辟 的 索引 块 上 去 ， 这 个 过 程 就 称 为 索引 块 的 分 裂 (INDEX BLOCK SPLIT) 。 


如 图 2-11 所 示 ， 当 有 新 值 插入 到 L4 叶 节点 块 的 时 候 ， 此 时 L4 叶 节点 块 是 “充满 ”状态 ， 已 经 没有 足够 的 空间 来 存储 新 值 了 ， 此 时 会 在 B2 分 支 节点 下 ， 分 裂 出 一 个 新 的 叶 节点 L5 来 存储 新 值 。 如 果 分 支 节 
点 B2 也 是 “充满 ”了 呢 ? 那 就 要 进行 分 支 节点 的 分 裂 ， 即 在 ROOT 根 节点 下 ， 分 裂 出 一 个 新 的 分 支 节点 出 来 。 依 此 类 推 ， 如 果 根 节点 也 “充满 ”了 ， 则 需要 进行 根 节点 的 分 裂 。 如 果 发 生 了 根 节点 的 分 裂 ， 
也 意味 着 B 树 的 高 度 (BTREE LEVEL) 增加 了 一 个 层次 。 对 真正 意义 上 的 树 来 说 ， 这 种 生长 是 好 事 ， 但 对 B 树 索引 来 说 ， 这 就 不 是 什么 好 事情 了 ，B 树 索引 的 高 度 是 需要 严格 控制 的 。 
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图 2-11 新 值 产生 索引 分 裂 


2 分 裂 的 类 型 


从 上 面 的 介绍 来 说 ,我们 大 致 可 以 将 索引 分 裂 归 为 三 种 类 型 : 根 节 点 分 裂 、 分 支 节点 分 裂 、 叶 节点 分 裂 。 当 然 ， 也 可 以 说 是 两 种 类 型 ， 因 为 根 节点 分 裂 实质 上 是 一 种 特殊 的 分 支 节点 分 裂 。 我 们 首先 需 
要 关注 的 是 其 中 叶 节 点 的 分 裂 ， 因 为 它 是 最 频繁 发 生 ， 对 性 能 影响 最 直接 的 因素 。 


我 们 说 过 分 裂 出 新 节点 后 ， 会 将 一 部 分 旧 有 的 数据 放 到 新 节点 上 去 。 按 照 数据 迁移 量 的 比例 ， 我 们 又 可 以 将 索引 分 裂 分 为 两 种 类 型 : 9-1 分 裂 和 5-5 分 裂 。 如 果 叶 节点 和 分 支 节点 同时 发 生 分 裂 ， 其 分 裂 
比例 的 类 型 是 相同 的 ， 即 要 么 都 是 9-1 分 裂 ， 要 么 都 是 5-5 分 裂 。 


: 9-1 分 裂 : 绝 大 部 分 数据 还 保留 在 上 昌 有 节点 上 ， 仅 有 非常 少 的 一 部 分 数据 迁移 到 新 节点 上 。 


: 5-5 分 裂 : 旧 节 点 和 新 节点 上 的 数据 比例 几乎 是 持平 的 。 


我 们 通常 所 说 的 索引 分 裂 ， 大 部 分 情况 都 指 的 是 9-1 分 裂 。 当 事务 向 索引 最 右 侧 的 叶 节 点 上 插入 一 条 大 于 或 等 于 现 有 索引 块 上 最 大 值 的 数据 ， 且 该 索引 块 上 不 存在 其 他 未 提交 的 事务 时 ， 如 果 没 有 足够 的 
空间 ， 就 会 发 生 9-1 分 裂 。 


很 遗憾 的 是 ， 当 发 生 左 侧 节点 上 插入 数据 的 时 候 ， 发 生 9-1 分 裂 就 会 出 现 一 些 问题 。 如 图 2-12 所 示 ， 当 向 左 侧 分 支 节点 插入 新 值 ， 即 使 其 兄弟 右 侧 分 支 节点 数据 区 中 没有 数据 (或 者 说 没有 右 节点 ) ， 
它们 的 父 节点 都 会 发 生 分 裂 ， 极 端 情况 下 甚至 会 促使 B 树 的 高 度 增长 ， 这 对 索引 性 能 来 说 是 很 悲剧 的 ， 这 一 缺陷 在 Oracle 10g 以 前 的 版 本 中 都 是 存在 的 。 
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相关 四 


从 Oracle 10g 开 始 ， 对 于 左 侧 节点 的 数据 插入 行为 ， 引 进 了 5-5 分 裂 的 方式 ， 修 正 了 9-1 分 裂 造成 的 缺陷 。 如 图 2-13 所 示 ， 当 左 侧 分 支 节点 B1 已 经 处 于 “充满 ”状态 ， 会 去 判断 其 兄弟 右 侧 分 支 节 点 B2 
是 否 有 空间 ， 如 果 有 ， 则 将 部 分 数据 (5 : 5 的 比例 ) 迁移 到 右 侧 分 支 节 点 上 ， 这 样 就 避免 了 分 支 节点 甚至 根 节点 的 分 裂 。 


图 2-12 左 节点 9-1 分 裂 
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5-5 分 裂 的 方式 也 不 是 万 能 的 ， 如 果 过 于 频繁 的 5-5 分 有 裂 也 会 造成 索引 空间 使 用 率 不 高 ， 使 得 索引 结构 看 上 去 像 一 个 “ 虚 胖子 ”， 不 够 “结实 ”， 同 样 会 造成 性 能 问题 。 


图 2-13 左 节 点 5-5 分 裂 


那 什么 时 候 会 发 生 5-5 分 裂 呢 ? 简单 地 说 ， 就 是 在 索引 需要 分 裂 ， 但 不 能 进行 9-1 分 裂 的 时 候 就 会 触发 5-5 分 袭 。 这 听 起 来 像 一 句 废话 ， 可 将 9-1 分 裂 的 条 件 反 过 来 看 ， 也 正 是 5-5 分 裂 发 生 的 条 件 : 
“ 左 侧 节 点 发 生 新 值 插入 时 〈 新 值 小 于 索引 中 的 最 大 值 ) ; 
:发生 DML 操作 ， 索 引 块 上 没有 足够 空间 分 配 新 的 ITIL 模 ; 


“ 新 值 待 插入 的 索引 块 上 存在 其 他 未 提交 的 事务 。 


对 比 一 下 9-1 分 裂 和 5-5 分 裂 的 发 生 场景 。9-1 分 裂 通常 是 索引 的 键 值 是 递增 的 ， 表 上 的 事务 并 发 量 比较 低 ， 可 保证 新 的 数据 块 上 有 较 大 的 空闲 空间 插入 新 值 。5-5 分 裂 通常 是 表 上 的 事务 并 发 度 较 高 ， 操 
作 的 数据 是 无 序 的 ， 需 保证 分 裂 的 新 旧 数 据 块 上 有 相对 较 大 的 空闲 空间 以 容纳 新 事务 的 操作 。 


总 体 来 看 ， 不 论 是 9-1 分 裂 还 是 5-5 分 裂 ， 对 于 性 能 来 说 ， 都 不 是 什么 好 事 。 索 引 块 的 分 裂 意味 着 索引 数据 一 定 范围 上 的 重组 ， 其 维护 代价 都 是 非常 高 昂 的 ， 应 该 尽 可 能 地 和 避免 不 必要 的 分 裂 发 生 。 


2.4.2 ”实例 分 析 


1.9-1 分 裂 分 析 


下 面 我 们 通过 一 些 实例 的 操作 来 进一步 深入 分 析 9-1 分 裂 的 过 程 吧 ， 这 将 是 一 个 很 美妙 的 过 程 ， 就 像 看 到 一 棵 树 生长 一 样 。 具 体 步骤 如 下 : 


步骤 1 创建 一 个 新 表 alex_t05 及 索引 ， 我 们 主要 考察 索引 idx_alex_t05 id : 


SQL> create table alex t05 (id number, name varchar2 (100) ) 7 
SQL> create index idx alex t05 id on alex t05 (id) 7 


步骤 2 向 alex_t05 表 中 顺序 地 添加 3000 行 数据 ， 此 过 程 我 们 将 开启 10224 事 件 进行 跟踪 : 


SQL> alter session set events '10224 trace name context 
2 forever,level 1'» 
Session altered 
SQL> declare 
2 begin 
3 for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 3000 loop 
4 insert into alex t05 values (i, 'alex'); 
5 end loop; 
6 commit; 
7 end; 
本 这 
SQL> alter session set events '10224 trace name context off'; 
Session altered 


下 面 是 10224 跟 踪 事 件 记录 的 索引 分 裂 过 程 的 日 志 ， 可 以 看 到 其 记录 了 5 次 索引 叶 节 点 数据 块 的 分 裂 ， 也 就 是 说 整个 过 程 发 生 了 5 次 索引 分 裂 。 因 为 测试 表 和 索引 都 是 新 建 的 ， 也 就 是 说 此 时 索引 树 结构 
应 该 有 6 个 叶 节点 数据 块 。 


splitting leaf,dba 0x010267a4,time 14:53:00.149 

kdisnew bseg_ srch cbk reject block -mark full,dba 0x010267a4,time 14:53:00.151 
kdisnew bseg : srch cbk rejecting block ,dba 0x010267a4,time 14:53:00.151 
kdisnew bseg srch cbk using block,dba 0x010267a6,time 14:53:00.152 

kdisnew bseg : srch cbk reject block -mark full,dba 0x010267a6,time 14:53:00.152 
kdisnew bseg srch cbk rejecting block ,dba 0x010267a6,time 14:53:00.152 
kdisnew bseg srch cbk using block,dba 0x010267a7,time 14:53:00.152 

splitting leaf,dba 0x010267a7,time 14:53:00.420 

kdisnew bseg_ srch cbk reject block -mark full,dba 0x010267a7,time 14:53:00.421 
kdisnew bseg : srch cbk rejecting block ,dba 0x010267a7,time 14:53:00.421 
kdisnew bseg srch cbk using block, dba 0x010267a8, time 14:53:00.421 

splitting leaf,dba 0x010267a8,time 14:53:00.652 

kdisnew bseg_ srch cbk reject block -mark full,dba 0x010267a8,time 14:53:00.652 
kdisnew bseg srch cbk rejecting block ,dba 0x010267a8,time 14:53:00.652 
kdisnew bseg : srch cbk using block, dba 0x010267a5， time 14:53:00.652 

splitting leaf,dba 0x010267a5,time 14:53:00.879 

kdisnew bseg_ srch cbk reject block -mark full,dba 0x010267a5,time 14:53:00.879 
kdisnew bseg srch cbk rejecting block ,dba 0x010267a5, time 14:53:00.879 
kdisnew bseg : srch cbk using block, dba 0x010267ae, time 14:53:00.881 

splitting leaf,dba Ox010267ae,time 14:53:01.128 

kdisnew bseg_ srch cbk reject block -mark full,dba 0x010267ae,time 14:53:01.128 
kdisnew bseg srch cbk rejecting block ,dba 0x010267ae,time 14:53:01.128 
kdisnew bseg srch cbk using block, dba 0x010267af, time 14:53:01.128 


步骤 3 ”再 来 验证 一 下 发 生 的 分 裂 是 不 是 发 生 了 9-1 分 裂 。 通 过 数据 字典 的 查询 ， 可 以 看 到 该 会 话 (因为 是 新 建 的 会 话 ) 制造 了 5 次 9-1 分 裂 ， 这 和 10224 事 件 跟踪 的 结果 是 不 谋 而 合 的 。 验 证 结果 如 下 所 


| 


SQL> select s.sid, n.name, s.value 


2 from v$sesstat s, v$statname n 

3 where s.statistic# = n.statistic# 

4 and sid in (select sid from VSmystat) 

5 and value > 0 

6 and n.name like '%split%®'; 
SID NAME, VALUE 
1621 leaf node splits 5 
1621 leaf node 90-10 splits 导 


步骤 4 ”再 来 分 析 一 下 索引 idx_alex_t05 id 的 结构 吧 ， 同 时 DUMP 出 索引 树 形 结构 。 


此 时 的 分 裂 就 索引 空间 的 使 用 率 来 说， 是 比较 高 效 的， 使 用 率 大 约 在 76% 左 右 。 从 DUMP 文 件 可 以 看 到 每 个 叶 节点 块 大 约 存储 570 个 条 目 ， 简 单 地 做 个 换算 ，769 充 盈 的 叶 块 可 以 存储 570 行 的 记录 , 那 
一 个 100% 充 一 的 块 即 可 以 存储 571/0.76 = 750 行 记录 。 


同时 我 们 看 到 索引 的 PCT_FREE=10%， 也 就 是 说 索引 的 叶 块 的 利用 率 可 以 达到 90%， 单 块 可 以 存储 记录 行 数 即 为 750x0.9= 675。 但 实际 情况 单 块 存储 的 记录 行 数 在 没有 达到 675 行 就 已 经 分 裂 
PCT_FREE 参 数 的 设置 被 忽视 了 。 当 发 生 9-1 分 裂 的 时 候 ，PCT_FREE 参 数值 仅仅 可 以 作为 参考 ， 不 知道 5-5 分 裂 的 时 候 是 否 也 是 一 样 呢 ?” 验 证 如 下 所 示 : 


HN 


SQL> analyze index idx alex t05 id validate structure; 
Index analyzed 
SQL> select height, 


2 round((del lf rows len/lf rows len)*100,2)||'%' ratio, 
3 pct used from index stats where name= 'IDX ALFX T05 ID'7 
HEIGHT RATIO ECT 1 USED 
2 0% 76 


SQL> select pct free from user indexes 
2 where index name='IDX ALEX T05 ID'; 
PCT_FREE 

10 

SQL> alter session set events 'immediate trace name 
2 treedump level 311979'; 

et begin tree dump 

branch: 0x10267a4 16934820 (0: nrow: 6, level: 1) 
leaf: 0x10267a6 16934822 (-1: nrow: 577 rrow: 577) 
leaf: 0x10267a7 16934823 (0: nrow: 570 rrow: 570) 
leaf: 0x10267a8 16934824 (1: nrow: 570 rrow: 570) 
leaf: 0x10267a5 16934821 (2: nrow: 570 rrow: 570) 
leaf: 0x10267ae 16934830 (3: nrow: 570 rrow: 570) 
leaf: 0x10267af 16934831 (4: nrow: 143 rrow: 143) 

ene end tree dump 


2.5-5 分 裂 分 析 


接 下 来 再 来 看 一 下 5-5 分 裂 的 情况 ， 它 和 9-1 分 裂 的 方式 和 原理 是 不 一 样 的 。 我 们 知道 有 三 种 情况 会 触发 5-5 分 裂 ， 我 们 来 逐一 测试 一 下 吧 。 


场景 1 左 侧 节点 发 生 新 值 插入 的 情况 。 


我 们 可 以 对 上 面 9-1 分 裂 的 例子 变换 一 下 ， 反 序 插入 3000 条 记录 ， 再 通过 10224 事 件 和 树 形 结构 的 DUMP 来 分 析 。 反 序 插入 记录 的 代码 如 下 所 示 : 


SQL> declare 


2 begin 

3 For i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 3000 loop 
4 insert into alex t05 values (3001-i, 'alex'); 

5 end loop; 加 

6 commit; 

7 end; 

8 / 


此 时 ， 我 们 注意 到 索引 同样 只 发 生 了 叶 节 点 块 的 分 裂 ， 但 是 同样 的 操作 ， 分 裂 次 数 由 5 次 增加 到 了 9 次 。 为 什么 呢 ? 因为 触发 的 是 5-5 分 裂 ，5-5 分 裂 导 致 索引 叶 节点 的 数据 块 使 用 率 不 高 ， 或 者 说 在 使 
率 还 不 高 的 时 候 就 发 生 了 分 裂 。 示 例如 下 : 


SQL> select s.sid, n.name, s.value 

用 from v$sesstat s, v$statname n 

3 where s.statistic# = n.statistic# 

4 and sid in (select sid from VSmystat) 

5 and value > 0 

6 and n.name like '%split%'; 
SID NAMP VALUE 
1621 leaf node splits 9 
1621 leaf node 90-10 splits 0 


所 以 ， 此 时 索引 空间 总 体 的 使 用 率 也 由 之 前 的 76% 下 降 到 了 48% ( 见 下 面 的 统计 信息 ) ， 从 索引 树 形 结构 的 DUMP 文 件 中 也 可 以 看 到 单 块 存储 的 记录 行 数 由 570 行 下 降 到 了 281 行 ， 说 明 此 时 索引 有 点 像 
个 “ 虚 胖 子 ”了 。 如 果 一 个 索引 上 频繁 发 生 5-5 分 裂 ， 则 这 个 “ 虚 胖子 ”将 变 得 越发 “虚弱 ”。 在 一 次 简单 的 查询 或 者 DML 操 作 的 时 候 ， 会 扫描 非常 多 的 索引 块 ， 直 接 导 致 O 次 数 的 增加 ， 特 别 是 在 并 发 度 
很 高 的 表 上 ， 这 样 的 变化 甚至 可 能 是 致命 的 ， 可 能 会 让 你 丧失 近 10 倍 的 响应 速度 。 当 然 ， 这 种 问题 可 以 通过 索引 重建 来 修复 ，2.5 节 会 具体 展开 介绍 。 


SQL> select height, 


2 round( (del 1f rows len/lf rows_len) *100,2)1|'%' ratio, 
3 pct used from index stats where name= 'IDX ALEX T05 ID'; 
HEIGHT RATIO PCT_USED 
2 ‘0% 48 


如 下 为 索引 树 形 结果 的 DUMP 日 志 : 


一 = 一 -一 begin tree dump 

branch: 0x10267a4 16934820 (0: nrow: 10, level: 1) 
leaf: 0x10267a7 16934823 (-1: nrow: 471 rrow: 471) 
leaf: 0x10267b0 16934832 : nrow: 281 rrow: 281) 
leaf: 0x10267af 16934831 
leaf: 0x10267ae 16934830 
leaf: 0x10267ad 16934829 


( 
' 
(1: nrow: 281 rrow: 281) 
( 
( 
leaf: 0x10267ac 16934828 ( 
( 
( 
( 
( 


0 
1 
2: nrow: 281 rrow: 281) 
3: nrow: 281 rrow: 281) 
4: nrow: 281 rrow: 281) 
leaf: 0x10267ab 16934827 (5 
leaf: 0x10267a6 16934822 (6 
leaf: 0x10267a5 16934821 (7 
leaf: 0x10267a8 16934824 (8 
ne end tree dump 


: nrow: 281 rrow: 281) 
: nrow: 281 rrow: 281) 
: nrow: 281 rrow: 281) 
: nrow: 281 rrow: 281) 


如 预期 的 结果 一 样 ， 在 发 生 5-5 分 裂 的 时 候 ，PCT_FREE 参 数 再 一 次 被 忽视 。 参 数 PCT_FREE 在 索引 创建 时 起 作用 ， 而 在 使 用 时 往往 被 忽略 。 如 下 是 索引 IDX_ALEX_T05 ID 的 PCT_FREE 参 数 设置 情况 : 


SQL> select pct free from user indexes 
2 where index name='IDX ALEX T05 ID'; 
PCT_FREE 


场景 2 DMIL 操 作 时 ， 索 引 块 上 没有 足够 空间 分 配 新 的 ITL 模 。 


这 种 情况 应 该 和 第 三 种 情况 (新 值 待 插入 的 索引 块 上 存在 其 他 未 提交 的 事务 ) 结合 起 来 一 起 看 会 更 加 清晰 。 两 种 情况 都 是 因为 应 用 的 并 发 度 高 而 引发 的 。 同 一 索引 数据 块 上 的 事务 数 超出 了 实际 允许 的 
ITL 数 ， 导 致 MAXTRANS 不 足 。 另 外 ， 从 Oracle 10g 开 始 ，MAXTRANS 的 值 被 强制 设置 为 255， 不 能 修改 ， 但 实际 ITL 覃 数 所 占 空间 一 般 不 能 超过 数据 块 大 小 的 一 半 ， 如 默认 8KB 大 小 数据 块 的 限制 为 169。 


我 们 模拟 一 个 高 并 发 的 例子 来 看 一 下 吧 ， 只 做 一 个 简单 的 insert 操 作 ， 并 发 度 设置 为 300 (大 于 169) ， 每 个 并 发 进程 循环 执行 100 次 。 


SQL> insert into alex t05 values 
2 (trunc (qbms_random.value ()*10000)， "alex'")7 


查询 并 发 插入 操作 前 后 的 系统 统计 信息 ， 做 个 差 值得 到 并 发 操作 的 等 待 事件 统计 和 索引 分 裂 状 态 统计 (整个 过 程 数 据 库 无 其 他 会 话 操作 ) 。 因 为 是 无 序 的 插入 ， 索 引 大 部 分 分 裂 情况 都 是 5-5 分 裂 。 而 从 
等 待 事件 来 看 ， 出 现 了 “enq: TX-allocate ITL entry” 等 待 事件 ， 意 味 着 出 现 了 数据 块 上 ITL 的 争 用 ， 当 然 这 其 中 包括 了 数据 块 和 索引 块 的 争 用 。 示 例如 下 所 示 : 


SQL> select event, total waits 


2 from v$system event 

3 where event in 

4 ('enq: TX - allocate ITL entry', "enq: TX - index contention'); 
EVENT TOTAL WAITS 
enq: TX - allocate ITL entry 18 
enq: TX - index contention 134 
SQL> select n.name, s.value 

2 from v$sysstat s, v$statname n 

3 where s.statistic# = n.statistic# 

4 and n.name like '%split%®'; 
NAME VALUE 
leaf node splits 5522 
leaf node 90-10 splits 53 
branch node splits 22 
root node splits 0 


在 索引 块 上 ， 有 以 下 两 种 情况 会 触发 “enq: TX-allocate ITL entry” 等 待 : 


“ 达到 数据 块 上 最 大 事务 数 限制 ; 


“ 递归 事务 ITL 争 用 。 


场景 3 新 值 待 插入 的 索引 块 上 存在 其 他 未 提交 的 事务 。 


前 面 说 到 这 种 情况 也 是 由 于 高 并 发 造成 的 ， 需 要 和 第 二 种 情况 结合 起 来 考虑 。 可 以 说 高 并 发 对 第 三 种 情况 的 影响 更 为 明显 。 


我 们 再 模拟 一 个 高 并 发 的 例子 ， 做 一 个 简单 的 顺序 的 insert 操 作 ， 并 发 度 仍 设置 为 300， 每 个 并 发 进程 循环 执行 仍 为 100 次 。 因 为 是 顺序 插入 的 ， 并 发 的 争 用 更 为 集中 到 最 右 侧 的 索引 节点 块 上 。lnsert 
语句 如 下 : 


SQL> insert into alex t05 values (seq alex t05 id.nextval, 'alex'); 


从 如 下 查询 结果 可 以 看 到 ， 索 引 的 分 裂 次 数 减 少 了 ， 但 是 等 待 事件 的 次 数 增加 了 ， 也 可 以 说 由 于 等 待 时 间 加 长 了 导致 发 生 索 引 块 的 分 裂 的 次 数 减 少 了 。“enq: TX-index contention” 是 一 个 与 索引 分 
裂 直接 相关 的 等 待 事件 ， 也 仅 由 索引 分 裂 才 会 触发 的 等 待 事件 。 当 一 个 索引 块 上 发 生 DML 操 作 ， 而 这 个 索引 块 正在 被 另外 一 个 事务 分 裂 ， 则 需要 等 待 分 裂 完成 后 才能 修改 上 面 的 数据 ， 此 时 就 会 发 
生 “enq: TX-index contention” 等 待 事件 。 因 为 争 用 的 索引 块 更 集中 了 ， 该 等 待 事件 发 生 的 次 数 也 就 增加 了 。 示 例如 下 所 示 : 


SQL> select event, total waits 


from v$system event 

3 where event in 

4 ('engq: TX - allocate ITL entry', "enq: TX - index contention'); 
EVENT TOTAL WAITS 
enq: TX - allocate ITL entry 285 
enq: TX - index contention 15492 
SQL> select n.name, s.value 

from VS$sysstat s，VS$Sstatname n 

3 where s.statistic# = n.statistic# 

4 and n.name like '%split%®'; 
NAME, VALUE 
leaf node splits 1304 
leaf node 90-10 splits 19 
branch node splits 4 
root node splits 0 


综 上 所 述 ， 发 生 5-5 分 裂 时 ， 如 果 是 第 一 种 情况 ， 新 值 小 于 索引 中 的 最 大 值 ， 这 在 索引 的 应 用 中 是 不 可 避免 的 ， 除 非 是 完全 理想 状态 (索引 聚 簇 因子 无 限 接近 于 数据 块 数 ) 下 。 换 而 言 之 ， 其 对 性 能 的 影 
响 可 以 不 用 太 多 关注 ， 因 为 我 们 做 不 了 什么 。 反 之 ， 应 该 更 多 关注 的 是 第 二 种 和 第 三 种 情况 ， 特 别 是 第 三 种 情况 ， 因 为 其 发 生 的 概率 和 影响 程度 都 较 大 。 


3. 高 并 发 优化 


了 解 了 问题 的 原理 和 发 生 过 程 ， 再 来 说 一 说 解决 的 办 法 吧 。 前 面 说 到 索引 的 争 
集中 在 “如 何 去 解 决 高 并 发 导致 索引 块 分 裂 的 争 用 ”上 面 。 


源 自 于 索引 的 分 裂 ， 因 为 这 是 一 个 代价 高 昂 的 操作 ， 而 触发 索引 分 裂 的 契机 就 是 索引 上 的 高 并 发 事务 操作 。 问 题 现 在 就 


济 


也 许 有 人 要 说 了 ， 索 引 块 上 有 分 裂 和 争 用 就 增加 一 些 ITL 模 来 增加 并 发 处 理 能 力 嘛 。 这 样 的 做 法 会 有 效 吗 ? 我 们 不 妨 修改 一 下 索引 的 initrans 参 数 来 试 试 看 ， 重 复 做 一 下 300 路 并 发 100 次 循环 的 简单 顺序 
插入 操作 : 


SQL> alter index idx alex t05 id rebuild initrans 10 pctfree 10; 


优化 后 的 效果 对 比如 表 2-4 所 示 ， 从 分 裂 情 况 来 看 ， 索 引 块 的 分 裂 总 次 数 明 显 下 降 了 ， 而 且 更 倾向 于 走 9-1 分 裂 ， 说 明 增 加 ITL 槽 后 索引 块 处 理 并 发 事务 的 能 力 加 强 了 。 但 不 幸 的 是 ， 等 待 事件 的 等 待 次 数 
反而 增加 了 ， 特 别 是 ITL 槽 争 用 的 等 待 更 加 明显 了 ， 所 以 说 修改 initrans 参 数 并 没有 真正 解决 问题 。 随 着 并 发 度 的 不 断 提 升 ，ITL 覃 的 争 用 也 越发 激烈 ， 就 好 像 干 军 万 马 买 火车 票 ， 原 来 2 个 窗口 ， 现 在 增加 到 
10 个 窗口 ， 其 实意 义 并 不 大 ， 还 是 需要 一 些 根本 的 解决 手段 。 


表 2-4 INITRANS 优 化 效果 


INITRANS 优化 


i 2472 
等 待 事件 
enq: TX - index contention 25380 
leaf node splits 391 
| leaf node 90-10 splits 人 84 
分 裂 情 况 
2 
0 


在 进行 下 一 步 的 优化 之 前 ， 我 们 先 来 思考 一 下 为 什么 会 形成 这 个 问题 呢 ? 是 的 ， 是 高 并 发 没 错 。 再 根本 一 些 的 原因 是 高 并 发 操作 过 于 集中 在 最 右 侧 的 索引 块 上 ， 如 果 我 们 能 把 这 种 “集中 ” 打 散 了 , 那 
问题 是 不 是 就 解决 了 呢 ? 接 下 来 ， 我 们 可 以 引进 反 向 键 的 B 树 索引 (REVERSE KEY INDEX) 来 打 散 这 种 “集中 ”， 试 着 解决 这 个 问题 看 看 。 


删除 掉 之 前 的 索引 ， 并 重建 一 个 反 键 索引 ， 如 下 所 示 : 


SQL> create index idx alex t05 id on alex t05 (id) reverse; 


此 时 的 优化 效果 如 表 2-5 所 示 ， 不 论 从 等 待 事件 ， 还 是 索引 分 裂 情况 来 看 ， 优 化 效果 都 是 比较 明显 的 ， 这 证 明 我 们 成 功 打 散 了 高 并 发 过 程 中 的 “集中 ”。 


表 2-5 反 键 索引 优化 效果 


初始 状态 INITRANS 优化 | 反 键 索引 优化 
enq: TX - allocate ITL entry 2:85 2472 860 
等 待 事件 
enq: TX - index contention 15492 1298 


leaf node splits 181 

leaf node 90-10 splits 4 
分 裂 情 况 

branch node splits 0 

root node splits 0 


为 什么 反 键 索 引 会 带 来 这 样 的 效果 呢 ? 主 要 是 由 反 键 索引 的 存储 结构 决定 的 ， 或 者 说 反 键 索引 就 是 为 了 解决 此 类 问题 而 衍生 出 来 的 B 树 索引 类 型 。 


对 于 普通 B 树 索引 来 说 ， 要 存储 数据 “1234”、“1235”、“1239”， 它 可 能 就 存储 在 同一 个 叶 节点 块 中 ， 如 图 2-14 的 左 图 所 示 。 但 是 反 键 B 树 索引 则 先 会 把 待 存储 的 数据 做 一 个 顺序 反 转 ， 成 
为 “4321”、“5321”、“9321” 后 再 进行 存储 ， 如 图 2-14 的 右 图 所 示 ， 本 来 连续 的 数据 有 可 能 存储 在 不 同 叶 节点 块 中 ， 这 样 就 避免 了 热点 索引 块 的 争 用 。 


图 2-14 ”普通 B 树 索引 和 反 键 B 树 索引 结构 对 比 


但 是 ， 我 们 说 反 键 索引 也 是 有 一 利 必 有 一 浆 ， 这 一 浆 则 同样 是 由 反 键 索引 的 存储 结构 带 来 的 。 我 们 在 数据 入 库 的 时 候 得 到 了 优势 ， 那 数据 读 取 呢 ? 查询 “1234”、“1235”、“1239” 记 录 ， 本 来 访 
问 一 个 索引 块 即 可 ， 现 在 需要 访问 三 个 了 ， 增 加 了 额外 的 MO 开销 。 所 以 ， 在 反 键 索引 的 应 用 中 特别 要 注意 的 是 ， 其 索引 列 上 的 查询 ， 尽 可 能 地 使 用 等 值 查询 ， 避 免 范围 查询 ， 这 样 可 以 避免 额外 的 MO 开 
销 。 下 面 是 一 个 强制 走 反 键 索引 的 范围 查询 ， 可 以 看 到 COST 开 销 是 大 得 可 怕 的 。 


SQL> select * from alex t05 where id between 106001 and 106010; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | l | 99 | 1146 | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX TOS | | 99 | 1146 (1)1 
喇 :, 变 什 INDEX FULL SCAN | IDX ALEX TOS5_ID | W753 | | 178 Ly 


当然 ， 我 们 大 可 不 必 因 为 有 弊端 而 不 用 它 ， 这 样 将 是 非常 可 惜 的 。 普 通 B 树 索引 和 反 键 B 树 索引 处 理 高 并 发 事务 的 对 比 情况 ， 如 图 2-15 所 示 。 横 坐标 轴 是 递增 的 高 并 发 数 ， 主 纵 坐 标 轴 对 应 柱状 
是 “enq: TX-index contention ”等待 事 件 的 平均 等 待 时 间 ， 次 纵 坐 标 轴 对 应 的 是 TPS 变 化 曲线 。 普 通 B 树 索引 对 应 的 是 较 高 的 柱状 图 和 较 低 TPS 曲 线 ， 反 键 B 树 索引 对 应 的 则 是 较 低 的 柱状 图 和 较 高 的 TPS 
曲线 。 


出 


点 : 


压力 测试 图 


100 120 140 160 180 200 220 240 260 


2-15 普通 B 树 索引 和 反 键 B 树 索引 处 理 高 并 发 事务 的 对 比 


280 300 320 340 360 380 400 420 440 460 480 
eAWT Normal eTPS Normal e AWT _ Reverse @ TPS Reverse 


300 


从 等 待 时 间 来 看 ， 反 键 索 引 几 乎 完全 消除 了 “enq: TX-index contention ”等待 ， 而 TPS 能 力也 有 4~ 5 倍 的 性 能 提升 。 相 信 这 完全 有 理由 让 大 家 接受 反 键 索引 了 。 


索引 的 高 效 使 用 不 仅 在 设计 阶段 需要 多 多 关注 ， 在 后 期 维护 阶段 也 是 不 容 忽 视 的 。 高 并 发 的 事务 处 理 往往 可 以 使 一 些 潜在 的 问题 浮现 出 来 或 更 为 突出 ， 对 于 索引 分 裂 和 生长 的 问题 大 致 可 以 总 结 以 下 几 


“ 避免 一 切 不 必要 的 索引 块 分 裂 发 生 ; 

“ 尽 可 能 简化 索引 结构 ， 移 除 不 必要 的 索引 字段 ; 

“ 使 选择 性 更 强 的 字段 在 前 ， 减 小 分 支 节点 的 大 小 ; 

: 有 可 能 的 话 ， 可 以 创建 压缩 索引 ; 

“ 对 于 更 新 较 少 的 OLAP 应 用 ， 考 虑 使 用 较 大 数据 块 的 表 空间 ; 


“ 定期 进行 索引 重建 ， 再 好 的 设计 和 使 用 都 无 法 完全 避免 索引 分 裂 问题 。 


2.5 索引 维护 


索引 对 于 性 能 保障 的 重要 性 是 不 言 而 喻 的 ， 一 个 优质 的 索引 是 性 能 的 润滑 剂 ， 相 反 ， 劣 质 的 索引 将 是 性 能 的 “ 绞 肉 机 ”。 通 过 2.4 节 的 介绍 ， 我 们 了 解 到 一 个 设计 优良 的 索引 ， 在 经 过 


别 是 OLTP 的 高 并 发 “摧残 ”之 后 ， 将 变 得 满目 净 关 ， 原 本 优质 的 索引 也 可 能 转变 为 劣质 的 。 


下 : “就 是 索引 的 定期 


这 就 需要 DBA 的 介入 ， 找 到 劣质 的 索引 ， 并 恢复 其 优质 的 本 相 。 索 引 的 后 期 维护 可 能 是 DBA 们 日 常 维护 工作 中 非常 
建 嘛 。” 不错， 但 是 面 对 成 百 上 干 甚至 上 万 的 索引 ， 会 不 会 有 种 束手无策 的 感觉 呢 ? 感觉 哪 都 是 问题 ， 却 无 从 下 手 。 另 外 一 方面 ， 索 引 是 否 也 有 它 的 生命 周期 呢 ? 当然 有 ， 索 引 和 


业务 是 息息相关 的 ， 业 务 下 线 了 ， 索 引 的 生命 周期 也 应 该 相应 进入 回收 期 。 


本 | 


本 节 将 围绕 索引 重建 展开 介绍 索引 后 期 维护 的 方法 ， 包 括 : 为 何 重建 索引 ， 何 时 重建 索引 ， 如 何 重建 索引 ， 以 及 索引 回收 和 相关 影响 分 析 。 


为 何 重建 索引 


1 .劣质 索引 的 代价 


随 着 业务 应 用 DML 操 作 的 进行 ， 索 引 的 结构 也 将 变 得 “松散 ”， 索 引 块 碎片 过 多 、 索 引 空 间 利 


下 面 我 们 来 看 一 个 劣质 索引 的 例子 。idx_alex_t05 id 经 过 一 系列 的 高 并 发 DML 操 作 后 ， 变 得 非常 “松散 ”， 


会 导致 索引 的 使 


率 低下 、 索 引 树 太 高 ， 这 些 问 题 


结构 分 析 的 结果 如 下 : 


常 业务 应 用 ， 特 


要 的 一 部 分 ， 同 时 也 可 能 是 最 费时 费力 的 一 部 分 。 有 人 可 能 会 简单 地 概括 一 


效率 变 差 


SQL> analyze index idx alex t05 id validate structure; 

SQL> select height, 
2 round((del 1f rows len/lf rows len)*100,2)||'%' ratio, 
3 pct used from index stats where name= 'IDX ALFX T05 ID'; 
HEIGHT RATIO PCT_USED 


3 495339 62 


此 时 如 果 进 行 一 些 DML 操 作 将 会 产生 一 些 额外 的 开销 。 示 例如 下 : 


SQL> delete from alex t05 where id between 466001 and 467000; 


| Rows Bytes 
| DELETE STATEMENT | | 1007 | ‘S5035 | 
| DELETE | ALEX T05 | | | 
INDEX RANGE SCAN| IDX ALEX T05 ID | 1007 | 5035 | 


db block gets 
consistent gets 
33 physical reads 
redo size 

26 sorts (memory) 
0 sorts (disk) 
rows processed 


如 果 重建 索引 idx_alex_t05_id 后 ,一 切 将 变 得 不 一 样 了 。 执 行 计划 中 可 以 看 到 |， 


“松散 ”结构 的 索引 在 处 理 同样 的 删除 操作 时 


， 付 出 更 大 的 COST 开 销 ， 这 部 分 开销 从 统计 信息 能 找到 原因 ， 


引 会 造成 较 多 的 逻辑 读 和 物理 读 ， 甚 至 产生 更 多 的 REDO 日 志 量 。 示 例如 下 : 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | DELETE STATEMENT | | 1001 | 5005 | 4 (0)| 00:00:01 | 
| 1 | DELETE | ALEX T05 | | | | | 
|* 坚 |] INDEX RANGE SCAN| IDX ALEX TOS5 ID | 1001 | 5005 | 4 (0)| 00:00:01 | 


1067 db block gets 
207 consistent gets 
25 physical reads 
317016 redo size 
26 sorts (memory) 
0 sorts (disk) 
1000 rows processed 


同样 ， 在 查询 操作 的 时 候 ， 劣 质 的 索引 也 会 因为 额外 的 开销 造成 性 能 问题 ， 及 时 让 “松散 ”的 索引 变 得 “结实 ”是 很 有 必要 的 ， 也 是 维持 索引 高 效 使 用 的 必需 行为 。 


2. 碎 片 的 由 来 


索引 结构 不 同 于 表 的 结构 ， 其 维护 行为 自然 也 不 同 于 表 的 维护 行为 。 对 于 索引 来 说， 它 是 没有 UPDATE 操 作 的 ， 它 只 有 INSERT 和 DELETE 操 作 。 
“ INSERT 操 作 : 当 有 新 值 进入 索引 ， 其 会 判断 是 否 有 废弃 的 键 值 可 以 重用 ， 如 果 有 即 重用 ， 和 否则 在 相应 节点 上 开辟 一 个 新 键 值 。 
:DELETE 操作 : 索引 键 值 的 节点 位 置 标示 为 删除 ， 但 并 不 实际 删除 该 键 值 ， 空 间 不 回收 。 这 是 由 索引 树 形 结构 的 特点 决定 的 ， 实 际 删 除 一 个 键 值 的 开销 是 非常 大 的 。 


“ UPDATE 操作 : 实质 上 是 先 做 DELETE ， 再 做 INSERT。 


索引 的 碎片 就 是 由 DELETE 操 作 产 生 的。 因为 键 值 已 经 标志 为 删除 状态 ， 但 并 未 实际 删除 掉 ， 这 样 的 废弃 键 值 被 认为 是 索引 的 碎片 ， 如 果 废 弃 键 值 被 重用 了 ， 则 视 为 碎片 的 再 利用 。 


索引 结构 中 只 有 一 个 层级 ， 一 个 叶 节点 ， 其 包含 5 个 索引 键 值 ， 此 时 因为 是 新 插入 的 数据 ， 索 引 结构 很 整齐 ， 没 有 碎片 。 示 例如 下 : 


SQL> select height, 
2 round( (del_ 1f rows len/lf rows_len) *100,2)1|'%' ratio, 
3 from index stats where name= 'IDX ALEX T05 ID'; 
HEIGHT RATIO I 

1 0% 

es begin tree dum 

leaf: 0x10267a4 16934820 (0: nrow: 5 rrow: 5) 

er end tree dump 


将 5 条 记录 都 删除 掉 ， 索 引 上 也 发 生 DELETE 操 作 ， 此 时 索引 5 个 键 值 都 被 标志 为 废弃 ， 没 有 有 效 键 值 ， 故 碎片 率 为 100%， 而 树 形 结构 的 DUMP 告 诉 我 们 ， 该 5 个 键 值 并 没有 删除 ， 空 间 也 没有 释放 掉 。 
验证 如 下 所 示 : 


SQL> select height, 
2 round( (del 1f rows len/lf rows_ len) *10072) | | '%®r ratio, 
3 from index stats where name= 'IDX ALEX T05 ID'; 
HEIGHT RATIO ae 

1 100% 

rs begin tree dum 

leaf: 0x10267a4 16934820 (0: nrow: 5 rrow: 0) 

一 一 一 一 end tree dump 


一 个 索引 中 碎片 多 了 ， 和 索引 空间 利用 率 低下 是 一 样 的 ， 都 是 其 “松散 ”的 一 种 表现 ， 都 是 会 影响 到 应 用 的 性 能 的 。 


Osa 索引 维护 的 重要 任务 就 是 及 时 消除 掉 不 必要 的 碎片 和 提高 索引 空间 利用 率 。 


2.5.2 ” 何 时 重建 索引 


索引 需要 定期 重建 来 保证 其 使 用 的 高 效 性 ， 但 是 这 个 时 间 点 不 是 那么 容易 把 握 的 。 不 是 什么 时 候 心血 来 潮 来 就 重建 一 下 ， 也 不 是 性 能 报警 了 才 去 考虑 重建 ， 它 应 该 是 有 一 些 标准 和 阅 值 来 控制 的 。 下 面 


1. 判 断 标准 


要 判断 也 是 需要 有 一 个 判断 标准 的 。 关 于 标准 也 是 各 有 各 的 说 法 ， 不 能 说 谁 对 谁 错 ， 只 能 说 各 有 各 的 适应 环境 。 这 里 我 们 也 说 一 个 被 大 家 普遍 认同 的 标准 ， 以 下 条 件 满 足 其 一 即 需要 考虑 索引 重建 : 


“ 索引 树 高 度 过 高 ， 如 : height>=4; 
“ 时节 点 碎片 率 过 多 ， 如 : DEL ILF_ROWS/LF_ROWS>20%; 
“ 叶 节 点 使 用 率 低下 ， 如 : PCT_USAGE<20%。 

2. 通 常 的 判断 方法 


有 了 判断 标准 的 阔 值 ， 我 们 可 以 进一步 看 一 下 判断 的 方法 。 说 到 方法 ， 大 部 分 读者 第 一 反应 应 该 都 是 做 索引 结构 分 析 吧 ? 不 错 ， 这 是 一 个 常规 性 的 做 法 ， 当 然 也 是 最 准确 的 做 法 。 上 面 我 们 也 已 经 介绍 
到 了 ， 它 大 致 有 两 个 步骤 。 


步骤 1 ”分析 待 重建 索引 的 结构 : 


SQL> analyze index idx alex t05 id validate structure; 


实质 上 这 个 步骤 和 DUMP 索 引 的 树 形 结构 是 差不多 的 ， 只 不 过 将 分 析 的 工作 交 给 了 数据 库 来 做 。 完 成 分 析 后 ， 其 会 将 结果 记录 到 一 个 名 叫 index _stats 的 视图 中 。 


步骤 2 接 下 来 就 是 从 index_stats 中 获取 我 们 需要 的 信息 了 : 


SQL> select height, 
2 round( (del_ 1f rows len/lf rows_len) *100,2) 1|'%' ratio, 
3 pct used from index stats where name= 'IDX ALEX T05 ID'; 


HEIGHT RATIO PCT_USED 


树 高 、 碎 片 率 、 空 间 利用 率 都 有 了 ， 而 且 步 骤 只 有 两 步 ， 一 切 看 上 去 很 美妙 ， 不 是 吗 ” 很 遗憾 ， 回 答 是 否定 的 。 步 又 2 固然 很 快捷 方便 ， 但 是 步骤 1 的 分 析 过 程 将 要 付出 高 昂 的 代价 。 不 仅 执行 起 来 很 
慢 ， 而 且 会 锁 表 ， 对 于 OLTP 在 线 系统 来 说 ， 这 样 的 分 析 是 不 可 能 完成 的 任务 ， 除 非 你 愿意 付出 高 额 性 能 损耗 作为 代价 。 


3. 灵 巧 的 判断 方法 


做 不 做 索引 结构 分 析 ? 这 往往 成 了 DBA 们 比较 纠结 的 问题 。 做 的 话 ， 代 价 太 大 ， 不 做 迟早 要 付出 代价 。 面 对 这 种 两 难 的 局 面 ， 相 信 大 家 都 会 选择 找 个 比较 空 的 时 间 段 去 做 ， 付 出 点 代价 至 少 比 迎 接 性 能 


崩溃 的 “洪水 猛兽 ”要 好 一 些 。 


其 实 ， 还 是 有 比较 灵巧 的 方法 的 ， 仪 需 付出 很 小 的 代价 就 能 完成 这 个 判断 。 这 里 我 们 可 以 解放 一 下 思路 ， 开 辟 一 个 新 的 思考 方式 。 


问题 1: 我 们 真正 需要 的 是 什么 呢 ， 是 索引 结构 分 析 过 程 吗 ? 不 是 。 我 们 真正 需要 的 是 那 三 个 判断 指标 而 已 。 


题 2: 我 们 需要 的 是 非常 准确 的 碎片 率 和 空间 利用 率 指标 值 吗 ? 不 是 。 我 们 需要 一 个 比较 接近 真实 值 的 大 致 估算 就 可 以 了 。 


可 


问题 3: 我 们 需要 关注 整个 索引 结构 吗 ” 不 需要 。 我 们 更 关注 的 是 叶 节点 ， 如 果 叶 节点 “松散 ”， 分 支 节点 也 不 会 好 到 哪里 去 ， 反 之 ， 就 不 必 考 虑 索引 重建 的 问题 了 。 


基于 以 上 三 点 ， 我 们 似乎 可 以 不 要 再 麻烦 地 去 分 析 索 引 结构 了 ， 可 以 变通 地 进行 大 致 的 估算 就 可 以 了 ， 而 估算 的 基础 就 是 表 和 索引 的 统计 信息 的 数据 。 不 要 说 这 个 也 没有 ， 对 于 CBO 优 化 器 来 说 ， 如 果 
没有 较为 准确 的 统计 信息 也 没有 必要 考虑 什么 索引 维护 的 问题 了 。 


如 何 去 做 估算 呢 ? 我 们 还 是 需要 从 索引 叶 节 点 结构 入 手 的 ， 来 做 一 次 “应 丁 解 牛 ” 吧 。 图 2-16 所 示 为 一 个 建 在 普通 表 上 的 索引 条 目 存 储 结构 ， 其 中 索引 条 目 头 为 2~ 3 个 字 节 ， 索 引 列 的 长 度 定义 为 1 个 字 
节 ， 索 引 键 值 的 字 节 数 取 决 于 该 列 的 实际 长 度 ，ROWID 长 度 定义 为 1 个 字 节 ，ROWID 为 6 个 字 节 (若是 建 在 分 区 表 上 的 全 局 索引 ， 其 ROWID 为 10 个 字 节 ) 。 这 样 我 们 可 以 估算 出 单个 索引 条 目的 存储 字 节 
数 INDEX_ROW LEN =10+COL LEN。 


索引 条 目 头 ‖」 键 列 长 键 列 值 I ROWID 长 | ROWID 


证 辣 | 酸 客站 交 5 


图 2-16 索引 条 目 存 储 结构 


接 下 来 ， 我 们 要 估算 一 下 一 个 索引 叶 节点 数据 块 中 能 存储 多 少 个 索引 条 目 。 一 个 数据 块 的 空间 不 是 全 部 都 能 用 存储 索引 条 目的 ， 先 要 去 除数 据 块 保留 部 分 (index_stats 中 “丢失 ”的 叶 节点 块 空间 ) 的 
192 个 字 节 ， 再 考虑 PCTFREE 参 数 预 留 的 比例 。 那 么 单 块 能 存储 的 索引 条 目 数 可 以 估算 为 (BLOCK_SIZE-192) * (1-PCTFREE/100) /INDEX_ROW LEN。 


现在 要 将 索引 的 全 部 条 目 存储 起 来 ， 我 们 还 需要 知道 索引 的 条 目 数 (NUM_INDEX_ROWS) ， 这 个 条 目 数 不 一 定 等 于 表 的 记录 行 数 。 那 存储 全 部 索引 条 目 需要 多 少 个 叶 节点 数据 块 呢 ? 


NUM _ INDEX ROWS 
(BLOCK SIZE-192 ) * ( 1-PCTFREE/100 ) /INDEX ROW LEN 


EST LEAF BLOCKS = 


有 了 这 个 估算 的 叶 节 点 数据 块 数 ， 再 将 其 与 实际 的 叶 节 点 数据 块 数 做 个 对 比 ， 就 可 以 得 到 索引 空间 的 有 效 利 用 率 了 。 用 100% 减 去 这 个 有 效 利 用 率 得 到 的 是 索引 的 碎片 率 (EST_FRAG_RATIO) ， 这 个 
碎片 率 和 通过 索引 分 析 得 到 的 碎片 率 是 不 一 样 的 ， 它 是 索引 分 析 碎片 率 和 索引 空洞 ( 叶 块 中 没有 使 用 的 部 分 ) 率 的 一 个 并 集 ， 可 以 说 它 同 时 反映 了 叶 节 点 碎片 率 和 叶 节 点 使 用 率 两 个 指标 。 


EST LEAF BLOCKS 
EST FRAG RAIIO = | 1- 一 -一 -一 -一 一 一 一 |“ 1009%0 
因 \ LEAF BLOCKS 


整理 一 下 就 可 以 得 到 如 下 计算 公式 : 
NUM _ INDEX ROWS* (10 十 COL LEN) 


一 
LEAF BLOCKS* (BLOCK SIZE-192 ) * ( 1-PCTFREE/100 ) 。 


EST FRAG RATIO = |1- 


我 们 通过 一 个 例子 实际 操作 一 下 看 看 吧 ， 先 通过 表 和 索引 的 统计 信息 数据 获取 公式 中 各 个 变量 的 值 ， 再 进行 计算 。 


LEAF_BLOCKS、NUM_INDEX_ROWS 和 PCTFREE 的 值 可 以 通过 查询 dba_indexes 数 据 字段 视图 获取 ， 查 询 如 下 所 示 : 


SQL> select leaf blocks, num rows, pct free from dba indexes 
2 where index name='IDX ALEX T05 ID'" 7 
LEAF BLOCKS NUM ROWS PCT FREE 


COL LEN 为 索引 列 的 实际 长 度 ， 我 们 没 办 法 去 计算 每 个 记录 行 的 实际 长 度 ， 可 以 使 用 统计 信息 中 平均 行 长 (AVG_COL LEN) 来 替代 ， 可 以 通过 查询 dba_tab_cols 视 图 获取 其 变量 值 。 查 询 如 下 所 示 : 


SQL> select avg col len from dba tab cols 
2 where table name = 'ALEX T05' and column name="'ID'; 
COLUMN NAME AVG COL LEN 


BLOCK_SIZE 就 是 数据 库 的 数据 块 大 小 ， 这 里 我 们 取 的 是 默认 值 8192 字 节 (Bytes) 。 


SQL> select value from v$parameter where name='db block size'; 
VALUE 


可 以 计算 出 估算 索引 的 碎片 率 (EST_FRAG_RATIO) 约 为 779%。 对 比 一 下 进行 索引 结构 分 析 的 结果 来 看 一 下 吧 。 此 时 叶 节点 块 的 使 用 率 是 519%， 碎 片 率 为 49.18%， 将 空洞 也 视 为 碎片 换算 一 下 ， 得 到 : 
碎片 率 = (1-92x51%x (1-49.18%) /92) x100% = 74%， 其 和 估算 的 77% 相 差 不 大 ， 估 算 的 碎片 率 基本 上 可 以 反映 索引 的 碎片 情况 。 索 引 结 构 分 析 查 询 结果 如 下 : 


SQL> select height, 
2 round( (del 1f rows len/lf rows_len) *100,2) |1|'%' ratio, 


3 pct used from index stats where name= 'IDX ALEX T05 ID'; 
HEIGHT RATIO PCT_USED 
3 49.18% 组 


随 着 表 中 数据 量 的 增加 ， 索 引 中 条 目 达 到 相当 规模 ， 此 估算 方法 得 到 的 碎片 率 也 将 更 加 准确 。 如 果 数 据 量 不 是 很 大 或 者 很 小 ， 此 方法 可 能 不 是 太 适 用 ， 当 然 数据 量 不 大 的 索引 也 没有 太 多 考虑 索引 重建 
的 必要 。 


2.5.3 ”如 何 重建 索引 


对 于 重建 索引 来 说 ， 似 乎 没有 太 多 的 好 办 法 ， 大 致 有 索引 重建 和 索引 重组 两 种 。 而 重组 和 重建 都 可 分 为 在 线 操作 和 离线 操作 。 


“ 离线 重组 : alterindex idx_alex_t05_id shrink space 
' 在 线 重 组 : alter index idx_alex_t05_id coalesce 
“ 离线 重建 : alterindex idx_alex_t05_id rebuild 


' 在 线 重 建 : alter index idx_alex_t05_id rebuild online 


对 于 索引 重组 来 说 ， 很 多 说 法 都 是 大 为 肯定 的 ， 快 捷 且 影响 小 。 事 实情 况 并 非 如 此 ，coalesce 与 shrink space 命 令 相 比 于 重建 索引 有 一 个 显著 的 缺点 : 不 会 导致 索引 降级 ， 且 coalesce 不 回收 索引 上 的 
空闲 空间 ，shrink space 空 间 回收 也 不 是 很 彻底 ， 这 对 高 并 发 的 OLTP 应 用 来 说 是 没有 太 大 意义 的 。 为 什么 说 coalesce 是 在 线 ， 而 shrink space 是 离线 呢 ? 主要 是 从 资源 消耗 上 来 说 的 。 


对 应 高 并 发 的 OLTP 系 统 ， 我 们 宁愿 选择 在 空闲 时 段 进 行 索 引 重 建 ， 以 换取 高 效 的 索引 性 能 。 对 比 两 种 重建 方式 ， 离 线 重建 索引 实质 上 是 对 现 有 索引 结构 的 扫描 和 重建 操作 ， 其 过 程 中 索引 本 身 是 不 可 f 
的 。 对 于 一 个 高 并 发 的 OLTP 系 统 来 说 ， 任 何 时 间 段 都 是 不 可 能 接受 的 ， 更 多 时 候 我 们 会 选择 在 线 重建 。 在 线 重建 实质 上 是 对 表 进行 扫描 ， 再 新 建 一 个 同样 的 索引 ， 然 后 进行 切换 和 | 旧 索 引 的 清除 。 


2.5.4 ”废旧 索引 清理 


索引 这 东西 和 表 不 一 样 ， 对 于 表 来 说 往往 可 以 很 明确 什么 时 候 新 建 ， 什 么 时 候 下 线 。 索 引 则 不 然 ， 新 建 索引 可 以 很 明确 ， 但 在 表 没 有 下 线 的 时 候 ， 我 们 往往 会 非常 纠结 索引 是 不 是 可 以 下 线 。 如 果 将 一 
个 尚 有 业务 使 用 的 索引 下 线 了 ， 那 将 意味 着 一 场 灾难 ， 由 此 而 导致 DBA 们 都 不 敢 删除 索引 ， 结 果 就 成 了 一 个 表 上 的 索引 越 来 越 多 。 


那 如 何 解决 这 个 问题 呢 ? 简单 来 说 就 是 严 进 严 出 ， 不 轻易 新 建 更 不 轻易 删除 。 如 前 面 章节 介绍 的 一 样 ， 新 建 的 时 候 要 做 好 性 能 影响 分 析 ， 删 除 的 时 候 更 要 严格 做 好 性 能 影响 分 析 。 那 废旧 索引 清理 的 时 
候 需 要 如 何 来 做 性 能 分 析 呢 ?Oracle 给 了 我 们 一 个 不 错 的 选择 ， 就 是 索引 的 使 用 情况 监控 (INDEX USAGE MONITOR) ， 


我 们 可 以 开启 索引 idx_alex_t05_id 的 使 用 监控 ， 然 后 可 以 通过 数据 字段 动态 性 能 视图 v$object_usage 来 进行 查询 监控 情况 ， 其 中 看 到 USED 栏 位 显示 该 索引 的 使 用 状态 为 “NO”， 那 在 此 次 监控 期 间 内 
该 索引 未 被 使 用 到 ， 可 以 考虑 删除 。 示 例如 下 所 示 : 


SQL> alter index idx alex t05 id monitoring usage; 

Index altered a 

SQL> select index name, monitoring, used from v$object usage; 
INDEX_NRME | MONITORING USED 


IDX ALEX TO5 TD YES NO 


仔细 思考 一 下 ， 这 个 方法 算 不 算 很 靠 谱 呢 ? 当然 不 算 ， 这 仅 是 一 种 治标 不 治本 的 方法 。 如 果 监 控 期 间 本 身 就 有 性 能 问题 ，SQL 的 执行 计划 “ 跑 偏 ” 了， 导致 索引 没有 用 到 ， 此 时 若 以 此 监控 情况 而 删除 
了 索引 ， 那 就 是 不 理智 的 。 或 者 说 ， 在 监控 期 间 内 ， 会 使 用 到 该 索引 的 SQL 很 幸运 的 都 没有 跑 ， 那 很 不 幸 的 就 又 会 出 现 索引 误 删 的 情况 。 为 了 减少 以 上 情况 的 出 现 ， 我 们 可 以 这 样 改 善 : 


“ 选择 数据 库 高 峰 期 实施 索引 监控 ， 以 及 尽 可 能 使 用 较 长 的 监控 周期 ; 


“ 可 以 对 特定 时 间 段 实施 多 次 监控 采样 。 


我 们 展开 一 下 想象 ， 是 谁 在 使 用 索引 ? SQL 语句 嘛 ， 而 此 方法 是 在 SQL 语句 执行 的 末期 进行 监控 ， 是 一 种 被 动 的 把 关 ， 故 不 为 推荐 ， 但 可 以 作为 一 种 辅助 手段 。 那 比较 靠 谱 的 做 法 是 什么 呢 ” 当然 是 在 
SQL 语句 执行 的 初期 就 进行 把 关 ， 或 者 说 在 SQL 语句 还 没有 执行 的 时 候 就 进行 把 关 ， 再 结合 索引 监控 进行 前 追 后 堵 ， 基 本 上 可 以 做 到 万 无 一 失 了 。 要 达到 这 个 目的 ， 我 们 就 需要 : 


“ 先 扫 描 程 序 代 码 ， 主 动 地 去 发 现 可 能 用 到 该 索引 的 SQL 语句 ; 
“ 同时 通过 Oracle 11g 引 进 的 SPA 等 工具 进行 必要 SQL 语句 的 抓 取 ; 


“ 最 后 根据 以 上 SQL 语句 进行 性 能 影响 分 析 〈 具 体 的 方法 之 后 的 章节 将 会 介绍 ) 。 


不 要 说 这 会 带 来 多 大 的 工作 量 ，DBA 的 工作 本 身 就 不 容易 ， 对 待 索引 新 建 和 删除 这 样 敏感 的 操作 更 加 需要 十 二 分 的 精神 ， 尽 可 能 地 把 工作 做 在 前 面 ， 主 动 预防 潜在 的 数据 库 问题 ， 才 不 会 出 现 本 可 以 不 
出 现 的 生产 故障 。 


2.6 本章 小 结 


纵 观 本 章 ， 主 要 介绍 的 是 在 Oracle 数 据 库 中 ， 如 何 去 进 行 高 效 的 索引 设计 和 维护 。 下 一 章 我 们 将 介绍 一 下 如 何 设计 高 效 的 表 。 


第 3 章 高效 表 设计 


本 章 要 点 : 


“ 数据 生命 周期 管理 ， 介 绍 如 何 进行 数据 在 生命 周期 各 个 阶段 的 管理 。 


“ 常用 字段 类 型 选择 ， 介 绍 常用 的 字段 类 型 的 选择 依据 和 优 缺点 。 


“ 行 链接 与 行 迁 移 ， 介 绍 在 表 的 设计 和 使 用 阶段 ， 行 长 控制 的 重要 性 。 
“ 分 区 表 的 使 用 ， 介 绍 如 何 有 效 地 使 用 分 区 表 。 
“ 适当 的 宛 余 ， 介 绍 以 空间 换取 时 间 的 方法 。 


“碎片 分 析 与 整理 ， 介 绍 表 在 使 用 阶段 的 维护 方法 。 


数据 库 之 所 以 被 认 作 是 一 套 系统 的 重 中 之 重 ， 是 因为 数据 库 是 数据 的 载体 ， 数 据 库 本 身 是 没有 太 大 价值 的 ， 其 价值 的 体现 在 于 实现 数据 的 高 效 访问 和 存储 。 在 数据 库 结构 中 ， 表 作为 数据 的 直接 载体 ， 
其 重要 性 的 关注 程度 不 言 而 喻 。 一 套 表 设 计 的 好 坏 直 接 决 定数 据 库 的 优 劣 ， 乃 至 整个 系统 运行 状态 的 好 坏 。 


在 OLTP 系 统 和 OLAP 系 统 中 ， 表 的 设计 思路 同样 有 着 很 大 的 差别 。 面 对 一 套 高 并 发 的 OLTP 系 统 ， 其 表 将 如 何 设计 呢 ?”Oracle 提 供给 我 们 很 多 种 类 型 表 的 选择 ， 比 如 IOT、 聚 簇 表 等 ， 看 上 去 很 好 很 高 
深 ， 实 际 上 也 是 很 有 应 用 价值 的 。 然 而 ， 面 对 高 并 发 的 应 用 ， 太 过 精妙 的 东西 往往 会 造成 不 可 预见 的 问题 和 难以 把 握 的 困难 ， 如 何 做 到 趋 利 避 害 呢 ? 大 道 至 简 ! 简单 的 堆 表 ( 即 通常 说 的 普通 表 ) 往往 是 最 
高 效 的， 对 那些 不 能 完全 理解 和 把 握 的 东西 ， 需 要 说 不 。 


简单 的 材料 并 不 意味 简单 的 设计 ， 就 像 蛋 炒饭 ， 最 简单 也 最 难 做 。 


本 章 将 为 大 家 展开 表 的 设计 和 应 用 之 妙 ， 从 数据 生命 周期 、 字 段 类 型 选择 、 字 段 顺 序 和 长 度 等 多 个 维度 深入 剖析 表 设 计 和 维护 过 程 中 的 方法 和 技巧 。 


3.1 数据 生命 周期 管理 


说 到 数据 生命 周期 管理 这 个 话题 ， 有 的 人 第 一 反应 可 能 会 是 : “一 个 很 虚 的 概念 ， 没 有 太 大 的 实际 意义 。” 也 有 的 人 会 认为 : “就 是 简单 的 数据 归档 ， 非 要 搞 出 一 个 很 牛气 的 名 字 。” 这些 都 是 因为 对 
数据 生命 周期 管理 不 够 了 解 ， 而 产生 的 略 带 偏颇 的 想法 。 


我 们 知道 数据 是 有 价值 的 ， 而 且 这 种 价值 是 始终 存在 的 。 然 而 ， 在 不 同 的 使 用 阶段 ， 其 价值 也 是 有 高 有 低 的 。 如 何 对 数据 进行 最 高 效 的 价值 管理 呢 ? 生命 周期 的 管理 方式 应 运 而 生 。 


3.1.1 什么 是 数据 生命 周期 管理 


数据 生命 周期 管理 (Information Lifecycle Management，ILM ) 是 数据 在 存储 媒介 网 络 之 内 流动 的 过 程 ， 而 这 种 过 程 需要 确保 系统 获取 需要 的 商业 信息 ， 并 向 客户 提供 一 个 良好 的 服务 水 平 ， 同 时 把 
单位 成 本 降 到 最 低 。 数 据 生命 周期 管理 还 要 满足 日 益 增长 的 对 于 成 熟 和 自动 化 存储 管理 的 需求 ， 这 可 以 在 保持 企业 对 于 商业 环境 变化 作出 快速 反应 的 能 力 的 同时 ， 提 高 个 人 的 工作 效率 。 数 据 生命 周期 管理 
作为 一 种 数据 管理 模型 ， 认 为 数据 有 一 个 从 产生 、 保 护 、 读 取 、 更 改 、 迁 移 、 存 档 、 回 收 、 再 次 激活 以 及 退出 的 生命 周期 ， 对 数据 进行 贯穿 整个 生命 周期 的 管理 需要 相应 的 策略 和 技术 实现 手段 。 信 息 生 命 
周期 管理 的 目的 在 于 帮助 企业 在 信息 生命 周期 的 各 个 阶段 以 最 低 的 成 本 获得 最 大 的 价值 。 


简单 来 说， 数据 生命 周期 就 是 识别 数据 价值 的 各 个 阶段 ， 并 有 针对 性 地 对 待 。 


数据 生命 周期 管理 是 一 个 很 宽泛 的 概念 ， 它 可 以 做 到 很 专业 ， 就 像 现 在 市 场 上 有 不 少 优秀 的 数据 生命 周期 管理 的 软件 和 供应 商 ， 当 然 也 有 很 多 公司 自己 架构 的 数据 生命 周期 管理 体系 也 非常 专业 。 如 果 
说 ， 我 们 现在 没有 很 明确 的 数据 生命 周期 管理 方法 ， 只 是 按照 一 定 的 规则 ， 对 数据 表 进 行 定期 的 迁移 、 备 份 、 归 档 和 删除 ， 那 么 恭喜 你 ， 这 也 是 在 做 数据 生命 周期 管理 。 对 广义 的 数据 生命 周期 管理 来 说 ， 
它 应 该 不 拘泥 于 某 种 软件 或 者 方法 论 ， 而 是 能 够 达到 数据 生命 周期 管理 的 目的 就 算是 成 功 的 。 


面 实现 的 数据 生命 周期 管理 图 ， 也 是 DBA 们 应 该 关心 和 考虑 的 。 


接 下 来 我 们 从 一 个 比较 抽象 的 概念 具体 来 看 看 ， 如 图 3-1 所 示 ， 这 是 一 个 简单 的 在 数据 库 


对 于 数据 的 产生 、 保 存 、 读 取 和 更 改 ， 基 本 上 都 是 在 生产 库 上 完成 的 ， 绝 大 多 数 的 数据 库 都 能 很 好 地 完成 这 几 个 任务 ， 往 往 接 下 来 的 迁移 和 归档 任务 容易 被 忽略 (压根 就 不 做 归档 ) 或 淡化 (简单 的 磁 
带 或 硬盘 备份 ， 需 要 时 再 导 回来 ) 。 比 较 好 的 做 法 应 该 是 建立 一 个 归档 库 ， 将 历史 数据 从 生产 库 下 线 ， 迁 移 到 归档 库 ， 归 档 库 的 数据 是 不 允许 更 改 的 ， 只 人 允许 部 分 业务 的 读 取 。 当 归档 数据 长 时 间 不 使 用 或 
需要 反 归档 时 ， 应 该 进入 回收 期 ， 进 行 数 据 再 激活 或 者 退出 生命 周期 (销毁 ) 。 


图 3-1 数据 生命 周期 管理 


当然 ,我们 也 不 是 为 了 做 数据 生命 周期 管理 而 去 做 数据 生命 周期 管理 的 。 一 般 来 说 ， 数 据 生命 周期 的 目的 可 以 大 致 分 为 如 下 四 个 : 

“ 满足 法 律 法 规 审计 的 需要 ， 建 立 专业 的 数据 管理 模式 ; 

“ 生产 数据 库 数据 量 日 益 庞 大 ， 多 年 积累 的 业务 数据 占据 了 大 量 的 存储 空间 ， 需 降低 存储 开销 ; 

“ 随 着 表 中 数据 量 的 不 断 增 长 ， 导 致 数据 操作 的 性 能 和 效率 逐渐 降低 ， 影 响应 用 系统 的 正常 使 用 ， 严 重 时 甚至 可 能 导致 系统 故障 ， 需 要 提升 数据 库 性 能 ; 


“ 容纳 海量 数据 的 庞大 数据 库 给 运营 维护 工作 带 来 挑战 ， 增 加 了 生产 数据 库 出 现 异常 和 故障 的 风险 ， 需 要 减少 故障 和 降低 数据 库 运 行 风险 。 


3.1.2 ”架构 模型 设计 


3.1.1 节 中 其 实 已 经 给 大 家 介绍 了 一 个 大 致 的 数据 生命 周期 管理 的 模型 ， 但 是 这 仅仅 是 一 个 大 致 的 模型 。 一 个 比较 成 熟 的 模型 应 该 更 加 细 化 一 些 ， 否 则 在 实际 操作 中 时 常会 感觉 到 无 法 很 好 地 贯彻 执行 。 


1 数据 分 类 识别 


在 架构 数据 模型 之 前 ， 我 们 首先 要 充分 地 认识 数据 ， 对 其 进行 合理 的 分 类 。 这 里 所 说 的 分 类 并 不 是 按照 业务 逻辑 来 分 类 ， 而 是 为 了 便于 数据 生命 周期 管理 ， 有 针对 性 地 进行 生命 周期 阶段 性 分 类 。 


从 实际 出 发 ， 看 一 下 实际 的 业务 数据 量 、 增 长 量 ， 以 及 各 类 型 数据 的 分 布 情况 吧 。 如 图 3-2 所 示 ， 业 务 系统 经 过 多 年 的 运行 ， 产 生 了 海量 高 价值 的 数据 。60% 是 非 活动 数据 ，20% 是 活动 数据 ，20% 是 亚 
活动 数据 ， 非 活动 数据 年 平均 数据 增长 量 可 达 30%~40%。 


我 们 可 以 根据 实际 应 用 的 经 验 总 结 ， 按 照 数 据 的 活动 程度 来 定义 几 种 数据 的 类 型 ， 也 就 是 数据 的 分 类 ， 如 下 : 
“ 活动 数据 : 直接 支持 当前 线 上 业务 的 ， 是 可 能 出 现 高 并 发 问题 的 重点 关注 对 象 ; 

“ 亚 活动 数据 : 支持 非 当前 线 上 业务 的 ， 但 是 尚 有 一 定 的 业务 访问 需要 ; 

: 历史 数据 : 线 上 业务 基本 上 不 需要 再 访问 的 业务 数据 ; 


“ 临时 数据 : 例如 日 志 数据 等 ， 只 是 支持 业务 短暂 的 使 用 。 


类 数据 类 型 分 布 率 

系 

红 10% 

扣 加 活动 数据 

E 回 亚 活动 数据 

有 活动 数据 历史 数据 
多 非 活动 数据 临时 数据 
全 加 增 量 数据 


mm mo 


图 3-2 ”数据 分 类 识别 


活动 数据 和 亚 活动 数据 ， 该 40% 数 据 是 我 们 需要 关注 的 重点 ， 也 是 高 并 发 问题 容易 频 发 的 数据 区 域 ，50% 的 历史 数据 和 10% 的 临时 数据 将 会 是 被 归档 的 标的 。 如 果 大 家 还 在 为 海量 数据 和 海量 高 并 发 的 
错综复杂 而 烦恼 ， 那 这 样 的 分 类 识别 就 势 在 必 行 了 。 通 常 来 说 ， 对 于 一 个 OLTP 线 上 系统 的 应 用 ， 海 量 高 并 发 不 会 伴随 着 海量 数据 同时 作用 的 ， 如 果 出 现 了 ， 就 是 数据 分 类 没 做 好 ， 势 必要 先 做 好 数据 分 类 识 
别 的 工作 。 


2 数据 架构 模型 


我 们 首先 来 看 一 下 数据 库 建 模 ， 一 套 成 熟 的 系统 会 包含 核心 系统 部 分 和 非 核心 子 系统 部 分 ， 其 重要 级 别 不 一 样 ， 对 应 的 后 台数 据 库 也 是 需要 区 分 开 的 ， 少 量 的 核心 库 加 上 一 定数 量 的 子 系统 库 构 成 一 套 
完整 的 数据 库 体系 。 


建 模 工作 需要 从 核心 库 开 始 ， 如 图 3-3 所 示 ， 右 侧 中 间 方 框 部 分 ， 这 是 一 个 核心 库 ， 先 区 分 三 个 区 域 : 业务 元 数据 、 在 线 业 务 数据 、 历 史 数 据 ， 可 以 分 隔 不 同 表 空 间 来 区 分 。 先 画 好 格子 ， 让 不 同类 型 的 
数据 各 按 其 位 。 


接 下 来 就 是 业务 元 数据 的 抽取 ， 从 元 数据 库 抽取 必要 的 业务 元 数据 ， 在 核心 库 中 分 配 的 独立 表 空 间 独立 存放 。 该 部 分 数据 不 宜 过 多 ， 原 则 上 该 部 分 数据 是 不 会 发 生 结构 的 变化 的 。 


其 中 ， 在 线 业务 数据 也 需要 进行 分 类 存放 ， 因 为 在 线 业 务 数据 直接 关系 到 整个 线 上 系统 的 性 能 ， 出 于 性 能 优化 的 考虑 ， 有 序 区 分 为 活动 数据 、 临 时 数据 、 亚 活动 数据 ， 避 免 相互 影响 。 同 时 ， 为 了 后 期 
的 数据 归档 方便 ， 可 以 加 入 分 区 表 的 使 用 ， 当 然 也 是 必须 先 考虑 到 业务 需求 的 。 


子 系统 库 的 建 模 参照 核心 库 进行 ， 可 以 视 为 核心 库 的 扩展 。 简 单 来 说 ， 就 是 要 做 好 先期 的 格式 化 ， 给 各 类 型 的 数据 画 好 格子 ， 各 按 其 位 。 


区 井 请 注 局 


图 3-3 ”数据 建 模 


对 于 频繁 变化 的 在 线 业 务 数据 ， 每 一 条 数据 记录 都 赋予 一 个 生命 时 间 戳 ， 来 记录 数据 的 接触 历史 ， 在 细 粒 度 上 保证 数据 的 校 输 。 如 图 3-4 所 示 ， 在 线 数据 包含 创建 人 、 创 建 时 间 、 更 新 人 、 更 新 时 间 的 信 
息 ， 归 档 数据 则 在 在 线 数据 的 基础 上 多 加 两 个 字段 : 归档 人 和 归档 时 间 。 


2012-01-01 


站 


新 时 间 2013-01-01 


1 


2012-01-01 


当 


2013-01-01 


归档 人 
归档 时 间 2013-04-01 


图 3-4 行 级 生命 堆 


这 种 设计 虽然 在 维护 上 需要 牺牲 掉 一 些 性 能 ,但 是 在 追溯 数据 接触 历史 方面 ， 其 作用 可 见 一 斑 。 后 期 的 数据 迁移 和 归档 也 会 变 得 简单 一 些 。 


立足 金融 行业 应 用 来 看 ， 保 证 数据 的 真实 准确 、 不 被 非法 纂 改 是 首要 的 ， 在 保证 数据 质量 的 前 提 下 ， 再 兼顾 其 性 能 考虑 ， 从 实际 使 用 效果 来 看 ， 维 护 得 当 也 不 会 造成 性 能 问题 。 当 然 ， 这 种 做 法 在 其 他 
行业 中 也 得 到 了 广泛 使 用 。 
3 数据 迁移 


再 来 看 一 下 数据 的 迁移 。 如 图 3-5 所 示 ， 建 模 阶 段 ， 我 们 提 到 子 系统 库 可 以 视 作 是 核心 库 的 扩展 ， 所 以 核心 库 和 各 个 子 系统 库 之 间 ， 存 在 双向 的 数据 交互 ， 而 子 系统 库 之 间 是 相对 独立 的 ， 不 可 以 数据 交 
互 。 这 里 ,我 们 可 以 使 用 Oracle 的 GoldenGate 来 作为 实时 同步 工具 ， 这 样 可 以 避免 传统 ETL 方 式 的 数据 交互 的 延迟 ， 也 可 以 解决 异 构 平台 和 异 构 数据 库 间 交互 的 限制 。 关 于 GoldenGate 的 使 用 ， 本 书 会 在 
第 二 部 分 展开 介绍 。 


归档 管理 平台 


归档 元 数据 库 
民有 坊 娄 


空间 回收 模块 


二 子 系统 库 


图 3-5 ”数据 迁移 


对 于 大 多 数 传统 行业 应 用 系统 的 数据 结构 来 说 ， 其 耦合 性 是 非常 高 的 ， 很 难 有 效 地 解 耦 ， 为 之 后 的 归档 造成 了 很 大 难度 。 如 何在 保证 逻辑 结构 的 同时 来 进行 归档 呢 ? 首先 就 需要 进行 业务 的 应 用 感知 ， 
建立 归档 数据 模型 ， 制 定 剥 离 策略 。 由 于 之 前 的 建 模 阶段 已 经 考虑 到 了 数据 分 类 存储 ， 此 处 的 步骤 也 就 变 得 比较 容易 了 。 


这 里 提 到 的 应 用 感知 ， 在 实际 应 用 中 ， 我 们 的 业务 数据 可 能 是 跨 表 、 跨 分 区 、 跨 表 空 间 。 核 心 表 的 对 应 子 表 很 多 ， 而 且 可 能 是 多 级 关联 ， 由 于 业务 逻辑 关系 紧密 ， 呈 现 出 不 可 分 隔 的 状态 。 这 个 时 候 
我 们 尽 可 能 在 保证 业务 逻辑 模型 的 前 提 下 ， 按 照 建 模 阶段 的 ER 关系 ， 从 下 往 上 逐 层 剥离 数据 ， 也 就 是 我 们 所 说 的 归档 建 模 ， 其 实 也 可 以 简单 地 看 为 逆向 建 模 。 


之 后 ， 就 是 将 过 期 的 在 线 数据 迁移 到 历史 数据 中 ， 并 记录 到 归档 元 数据 库 。 


是 不 是 到 此 就 结束 了 呢 ? 其 实 并 没有 ， 对 于 在 线 业 务 数据 ， 还 需要 进行 空闲 空间 回收 ， 回 收 不 必要 的 空间 ， 给 在 线 表 “减肥 ”， 一 方面 释放 了 存储 空间 ， 另 一 方面 优化 了 性 能 。 


4 数据 归档 


对 于 线 上 和 剥离 出 来 的 历史 数据 ， 过 期 后 ， 同 样 需 要 从 线 上 库 中 分 离 出 去 。 由 于 之 前 已 经 从 逻辑 上 剥离 ， 此 时 的 物理 分 离 就 变 得 相对 简单 ， 影 响 较 小 。 将 历史 数据 的 表 空 间 从 线 上 库 分 离 ， 转 存 到 对 应 的 
归档 数据 库 ， 并 将 归档 元 数据 记录 到 归档 元 数据 库 。 


值得 提 一 下 的 是 ， 历 史 数 据 的 归档 数据 库 不 必要 区 分 核心 库 和 子 系统 库 。 因 为 核心 库 和 子 系统 库 同属 于 一 个 系列 的 应 用 ,我 们 的 归档 数据 库 后 期 是 需要 用 作 线 下 数据 分 析 的 ， 集 中 管理 便于 数据 的 采 
集 ， 不必 像 线 上 库 一 样 过 多 地 去 考虑 性 能 上 的 实时 响应 ， 甚 至 不 要 给 归档 表 建 任何 的 索引 ， 除 非 线 下 应 用 有 需求 。 


是 不 是 就 此 结束 了 呢 ? 当然 不 是 。 如 图 3-6 所 示 ， 我 们 说 数据 生命 周期 管理 ， 有 数据 的 产生 就 有 数据 的 销毁 。 对 于 严重 过 期 的 数据 ， 我 们 可 以 转 到 廉价 的 存储 设备 保存 ， 进 而 可 以 考虑 销毁 。 


数据 生命 周期 管理 


系列 二 子 系统 库 归档 管理 平台 


系列 二 核心 库 


ET 


图 3-6 ”数据 归档 


另 一 方面 ， 当 遇 到 特殊 情况 ， 需 要 回归 已 归档 的 历史 数据 时 ， 我 们 不 得 不 进行 反 归档 ， 并 将 历史 数据 再 次 激活 ， 调 整 归档 策略 ， 避 免 反 归档 数据 再 次 被 归档 。 这 一 过 程 也 是 需要 记录 到 归档 元 数据 库 
的 。 值 得 一 提 的 是 ， 很 多 规范 要 求 严格 的 公司 是 不 允许 数据 的 反 归 档 的 。 


3.1.3 ”数据 分 层 存储 


什么 是 数据 的 分 层 存储 呢 ? 如 图 3-7 所 示 ， 按 照 我 们 设计 阶段 的 数据 生命 周期 概念 来 看 ， 数 据 有 五 种 状态 : 活动 的 、 亚 活动 的 、 历 史 的 (包括 临时 数据 在 内 ) 、 归 档 的 以 及 回收 销毁 的 。 
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应 


线 上 业务 线 下 分 析 
vyvY 


存储 


高 端 存 储 中 端 存储 低 端 存储 廉价 存储 


图 3-7 数据 分 层 存储 对 应 


活动 数据 和 亚 活动 数据 ， 是 我 们 数据 体系 的 主体 ， 支 持 的 是 线 上 业务 ， 当 然 必 须 保存 在 高 端 存储 设备 上 。 而 历史 数据 和 归档 数据 支持 的 是 线 下 分 析 的 需求 ， 其 重要 性 和 业务 压力 较 线 上 业务 低 ， 可 以 保 
存在 中 低 端 存储 设备 上 。 而 对 于 回收 销毁 的 数据 ， 没 有 业务 意义 ， 廉 价 保存 或 不 保存 即 可 。 


以 上 按照 重要 性 和 业务 压力 大 小 ， 有 区 别 地 保存 数据 就 是 我 们 所 说 的 数据 分 层 存 储 。 


数据 的 分 层 存 储 在 生命 周期 管理 中 ， 除 了 出 于 性 能 的 考虑 ， 同 样 也 是 出 于 成 本 的 考虑 。 了 解 了 实际 应 用 的 数据 情况 ， 下 面 我 们 通过 一 道 简单 的 应 用 题 来 分 析 一 下 成 本 的 问题 。 


如 表 3-1 所 示 ， 假 设 我 们 现在 有 一 个 5TB 的 数据 库 ， 对 应 一 套 灾 备 环境 ， 共 计 10TB 数 据 量 ， 年 均 增长 率 30%。 为 了 方便 计算 ， 假 设 10TB 约 等 于 10000GB。 


表 3-1 分 层 存储 成 本 计算 
和 rT 
容量 (GB) 次 年 增长 
低 并 EEC EEC ¥54 000 
廉价 ¥150 


合计 10 000 ¥4 500 000 ¥1 350 000 10 000 ¥2 070 500 ¥621 150 


先 看 单一 部 署 的 情况 ， 都 使 用 高 端 存储 设备 ， 首 年 部 署 的 费用 为 450 万 元 ， 第 二 年 费用 增长 了 135 万 元 。 


再 看 层级 部 署 的 情况 ，4000GB 数 据 使 用 高 端 ，1000GB 中 端 ，4000GB 低 端 ，1000GB 廉 价 ， 首 年 部 署 费用 总 计 约 为 207 万 元 ， 次 年 增长 约 为 62 万 元 。 


可 以 看 到 采用 层级 部 署 后 ， 成 本 节省 超过 50%。 面 对 这 么 大 幅度 的 成 本 节省 ，CFO 还 有 可 能 说 不 吗 ? 补充 说 一 句 ， 表 格 中 的 价格 数据 为 方便 计算 和 展示 ， 仅 供 参 考 。 


3.2 ”常用 字段 类 型 选择 


作为 一 位 数据 库 架 构 师 或 者 数据 库 管理 员 ， 你 可 能 会 花 很 多 时 间 去 研究 高 可 用 架构 、 分 布 式 处 理 架构 、 高 并 发 设计 架构 ， 等 等 ， 确 实 这 些 都 是 很 值得 研究 和 探讨 的 。 但 是 架构 设计 好 了 ， 忽 略 掉 了 一 些 
关键 细节 问题 ， 往 往 会 毁 了 整个 架构 ， 表 的 字段 类 型 选择 就 是 这 样 一 个 细节 。 


说 起 常用 的 字段 类 型 ， 大 家 都 会 想到 NUMBER、CHAR、VARCHAR2、DATE、LO8B 等 。 没 错 ， 这 些 字段 都 是 经 常会 使 用 到 的 ， 选 择 起 来 看 似 也 非常 简单 。 然而， 实际 情况 往往 会 出 现 没 得 选择 比 有 的 
选择 更 好 的 时 候 。 比 如 ，DATE 类 型 的 字段 ， 如 果 我 们 的 应 用 只 需要 精准 到 秒 级 的 日 期 时 间 ， 相 信 谁 也 不 会 去 用 TIMESTAMP 类 型 的 字段 。 如 果 是 跨国 的 业务 系统 呢 ? 相信 大 家 都 会 选择 保存 一 个 对 应 的 格林 
威 治 时 间 ， 并 且 选 择 UTF 字 符 集 的 字段 设计 。 但 是 ， 如 果 对 于 简单 的 数字 存储 呢 ? 大 部 分 人 会 选择 NUMBER 类 型 的 ， 也 有 的 人 会 选择 VARCAHR2 类 型 ， 还 有 的 人 会 选择 CAHR 类 型 ， 并 且 都 可 能 会 有 各 自 充 
分 的 理由 。 


下 面 我 们 将 针对 几 种 常见 的 字段 类 型 进行 一 些 对 比分 析 和 选择 。 


3.2.1 VARCHAR2 与 CHAR 


VARCHAR2 与 CHAR 这 一 对 好 朋友 ， 可 谓 是 相互 竞争 多 年 的 对 手 ， 各 自 有 一 番 用 武之 地 。 很 不 幸 的 是 ， 近 年 来 看 到 不 少 的 数据 库 中 几乎 已 经 没有 了 CHAR 类 型 字段 的 身影 。 从 某 种 意义 上 来 


说 ，VARCHAR2 是 可 以 完全 蔡 代 CHAR 的 ， 除 非 不 需要 考虑 性 能 的 问题 。 也 许 有 的 人 会 说 ， 那 点 性 能 损失 算 什 么 。 但 你 是 否 考虑 过 面 对 高 并 发 压力 的 时 候 呢 ? 一 点 细微 的 性 能 差异 会 被 无 限 倍数 地 放大 ， 那 
时 谁 还 敢 说 这 点 性 能 损失 算 什 么 呢 ? 


讲 一 下 两 者 的 区 别 : 


.CHAR 的 长 度 是 国定 的 ， 而 VARCHAR2 的 长 度 是 可 以 变化 的 。 比 如 : 存储 字符 串 “ABCDE”， 对 于 CHAR (10) ， 表 示 存 储 的 字符 将 占 10 个 字 节 ， 其 中 包括 5 个 空 字 符 。 而 同样 的 VARCHAR2 (10) 
则 只 占用 5 个 字 节 的 长 度 ，10 个 字 节 只 是 上 限 值 ， 当 存储 的 字符 小 于 10 时 ， 按 实际 长 度 存储 。 

“ 因为 CHAR 是 定 长 的 ， 省 去 了 判断 字段 实际 长 度 再 寻 址 的 操作 ， 其 效率 比 VARCHAR2 的 效率 稍 高 。 但 CHAR 比 VARCHAR2 浪 费 空间 ， 要 想 获得 效率 ， 就 必须 牺牲 一 定 的 空间 ， 这 是 我 们 在 数据 库 设 计 
上 常 说 的 “以 空间 换取 时 间 ”。 

“ VARCHAR2 虽 然 比 CHAR 节 省 空间 ， 但 是 如 果 一 个 VARCHAR2 列 经 常 被 修改 ， 而 且 每 次 被 修改 的 数据 的 长 度 不 同 ， 就 会 引起 行 迁移 (Row Migration) 现象 ， 造 成 多 余 的 I/O ， 这 是 数据 库 设 计 和 调整 中 
要 尽力 避免 的 ， 在 这 种 情况 下 用 CHAR 代 替 VARCHAR2 会 更 好 一 些 。 


从 其 各 自 特 点 的 区 别 ， 可 以 总 结 出 各 自 的 应 用 场景 : 


(1) CHAR 类 型 的 应 用 场景 

“ 该 列 中 各 行 的 数据 长 度 基 本 上 是 一 致 的 ， 且 长 度 不 宜 过 长 ， 如 身份 证 号 码 可 使 用 CHAR (18) ; 
“ 数据 更 新 频繁 查询 较 少 ， 可 防止 行 迁 移 发 生 的 概率 ， 同 时 尽 可 能 少 建 索引 ; 

“DDL 操作 非常 少 ，CHAR 类 型 字段 增加 长 度 的 开销 是 非常 大 的 ; 

(2) VARCHAR2 类 型 的 应 用 场景 

“ 该 列 中 各 行 数据 长 度 不 规则 ， 且 差异 较 大 ; 

* 数据 更 新 较 小 ， 但 是 查询 操作 频繁 ， 适 量 建立 索引 ; 


: DDL 操 作 较 少 ，VARCHAR2 类 型 字段 增加 长 度 也 会 加 大 行 迁 移 发 生 的 概率 。 


3.2.2 NUMBER 与 VARCHAR2 


NUMBER 与 VARCHAR2 类 型 的 字段 ， 第 一 反应 可 能 会 是 绑 定 变量 隐 式 转换 ， 导 致 查询 优化 器 成 本 计算 不 准 ， 索 引 不 被 识别 ， 执 行 计划 跑 偏 。 但 是 ， 会 不 会 首先 联系 到 字段 类 型 本 身 的 性 能 差异 呢 ? 一 
般 来 说，CPU 在 做 数值 计算 的 效率 要 比 做 字符 串 计 算 的 效率 高 不 少 。 同 样 对 于 “12345” 的 存储 和 计算 ， 如 果 选 择 数值 型 字段 的 存储 ， 在 查询 和 联 立 的 时 候 ， 速 度 要 比 字符 串 类 型 的 快 很 多 。 


下 面 我 们 通过 一 个 两 张 表 联 立 查询 的 例子 来 证 明 一 下 吧 。 具 体 步 又 如 下 所 示 : 


步骤 1 创建 四 张 表 ，alex_t311 和 alex_t312 均 包含 两 个 varchar2 (5) 类 型 的 字段 ， 而 alex_t321 和 alex_t322 均 包含 两 个 number (5) 类 型 的 字段 : 


SQL> create table alex t311 (idl varchar2(5), id2 varchar2 (5) ) ; 
SQL> create table alex t312 (idl varchar2(5), id2 varchar2 (5) ) 7 
SQL> create table alex t321 (idl number (5), id2 number (5)); 
SQL> create table alex t322 (idl number(5), id2 number (5)); 


步骤 2 ”分 别 给 四 个 表 新 建 2 万 条 记录 行 ， 内 容 均 为 “12345” ， 以 作 测试 对 比 : 


SQL> declare 

2 begin 

入 for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 20000 loop 
4 insert into alex t311 values ('12345', '12345'); 
每 insert into alex t312 values ('12345', '12345'); 
屯 insert into alex t321 values (12345, 12345); 
已 insert into alex t322 values (12345, 12345); 
6 end loop; 
7 commit; 
8 end; 
9 


步骤 3 ”做 一 次 两 个 列 的 笛 卡 儿 积 ， 对 比 其 性 能 : 


SQL> select count (*) from alex 七 311 
2 join alex 七 312 
3 using (idI，id2) 7 
COUNT (*) 

400000000 

Elapsed: 00: 00: 57.72 

SQL> select count (*) from alex 七 321 
2 join alex 七 322 
3 using (idI，id2) 7 
COUNT (*) 

400000000 

Elapsed: 00: 00: 55.81 


从 以 上 测试 结果 可 以 看 到 ， 待 测试 的 数据 是 一 样 的 ， 返 回 的 结果 也 都 是 4{Z 条 记录 的 笛 卡 儿 积 ，NUMBER 类 型 字段 的 返回 时 间 为 55.81 秒 ， 明 显要 比 VARCHAR2 类 型 的 57.72 秒 更 快 。 这 也 是 在 告诉 我 
们 ， 对 于 数值 类 型 的 字段 尽 可 能 使 用 数值 类 型 的 字段 去 存储 ， 不 要 为 了 图 方便 ， 不 管 三 七 二 十 一 都 使 用 /ARCHAR2 类 型 的 字段 。 在 这 方面 ，Oracle 的 DBA 可 能 需要 向 MySQL 的 DBA 学 习 一 下 ， 设 计 上 做 到 
精打细算 ， 富 日 子 也 要 学 会 穷 过 ， 这 样 面临 高 并 发 考验 的 时 候 ， 才 能 更 加 游 思 有 余 。 


另 一 方面 ， 隐 式 转换 的 问题 也 是 需要 注意 的 ， 不 仅仅 在 绑 定 变量 和 优化 器 成 本 计算 方面 ， 上 面 的 测试 例子 如 果 进 行 了 隐 式 转换 ， 效 率 将 会 是 最 差 的 。 我 们 扩展 做 一 下 这 个 测试 如 下 : 


步骤 4 做 一 次 包含 隐 式 转换 的 两 个 列 的 笛 卡 儿 积 : 


SQL> select count (*) from alex 七 311 
2 join alex 七 322 
3 using (idI，id2) 7 
COUNT (*) 

400000000 

Elapsed: 00: 01: 16.19 


测试 结果 告诉 我 们 ，NUMBER 和 VARCHAR2 的 联 立 在 效率 上 比 VARCHAR2 和 VARCHAR2 的 联 立 更 低 。 再 次 需要 声明 一 下 ， 隐 式 转换 必须 要 避免 。 


NUMBER 类 型 的 字段 在 使 用 上 是 非常 灵活 的 ， 其 精度 和 标 度 都 是 可 以 指定 的 ， 也 可 以 什么 都 不 指定 ， 让 Oracle 自 己 管理 。 但 凡 让 Oracle 自 己 管理 的 东西 ， 我 们 可 以 称 为 粗放 管理 方式 ，DBA 是 很 难 把 控 
的 。NUMBER 类 型 字段 的 设置 也 是 一 样 ， 如 果 我 们 可 以 很 明确 精度 和 标 度 的 情况 ， 就 尽 可 能 地 明确 指定 。 


看 一 看 下 面 的 例子 ， 如 果 不 指定 NUMBER 的 精度 和 标 度 ， 对 于 无 法 除 尽 的 小 数 存 储 ， 将 会 用 足 NUMBER 字 段 的 21 个 字 节 ， 这 将 是 存储 空间 的 很 大 浪费 。 


SQL> create table alex t31 (idl number, id2 number (5,2)); 
SQL> insert into alex t31 values (1/3, 1/3); 
SQL> select * from alex t31; 

ID1 ID2 加 


0.33333333 .33 


字段 长 度 是 一 定 的 。 但 从 性 能 上 来 说 ， 


另 一 方面 ， 值 得 一 提 的 是 Oracle 的 另外 两 种 存储 数值 的 字段 类 型 : BINARY_FLOAT 和 BINARY_DOUBLE， 这 两 个 浮 点 数 的 字段 类 型 是 不 能 指定 精度 和 标 度 的 ， 
浮 点 数字 段 类 型 是 有 一 定 优势 的 ， 如 下 例子 的 分 析 。 


步骤 5 新 建 两 个 包含 binary float 类 型 字段 的 表 ， 同 样 分 别 插入 2 万 条 记录 行 ， 再 做 一 次 两 个 列 的 笛 卡 儿 积 ， 对 比 其 与 number 类 型 的 性 能 : 


SQL> create table alex t331 (idl binary float, id2 binary float); 
SQL> create table alex t332 (idl binary float, id2 binary float); 
SQL> select count (*) from alex t331 

2 join alex t332 加 

3 using (idI，id2) 7 

COUNT (*) 

400000000 
Elapsed: 00: 00: 55.02 


从 测试 结果 看 到 ， 其 返回 时 间 有 一 定 的 缩短 ， 对 于 性 能 要 求 比较 高 的 表 和 字段 设计 ， 可 以 考虑 使 用 BINARY_FLOAIT 或 BINARY_DOUBLE 类 型 字段 蔡 代 NUMBER 类 型 。 


3.2.3 ”主键 字段 的 选择 


说 起 主键 字段 的 选择 ， 大 家 应 该 会 很 快 联系 到 一 些 业务 相关 的 1D 号 或 者 通过 SEQUENCE 自 增长 生成 的 序列 号 ， 这 些 有 序 的 序列 确实 是 一 个 不 错 的 选择 ， 如 果 在 没有 并 发 压力 的 前 提 下 。 


这 个 问题 在 上 一 章 的 高 并 发 索引 优化 中 其 实 已 经 提 及 到 了 ， 当 并 发 压力 较 大 时 ， 主 键 如 果 呈 现 SEQUENCE 式 的 递增 ， 就 会 导致 主键 索引 右 侧 叶 节 点 分 裂 的 争 用 ，“enq: TX-index contention” 等 待 
事件 也 随 之 出 现 ， 直 接 影 响 到 表 的 读 写 性 能 。 


那 接 下 来 ， 如 何 选择 主键 字段 将 是 我 们 要 讨论 的 重点 问题 。 以 下 是 关于 主键 字段 选择 的 一 些 注意 事项 和 建议 : 


“主键 字段 必须 非 空 且 唯 一 ， 这 个 是 基本 原则 ， 否 则 违反 主键 定义 。 

' 主键 字段 结构 不 能 改变 。 主 键 最 大 功能 就 是 为 了 唯一 标示 一 条 记录 行 ， 其 值 的 变化 意味 着 该 行 记 录 违 反 了 生命 周期 的 管理 模式 。 另 外 ， 必 然 带 来 子 表 数据 的 一 些 级 联 维护 ， 同 时 以 它 作为 外 键 的 子 表 
上 会 产生 锁 ， 子 表 外 键 上 有 索引 ， 则 会 产生 行 锁 ， 没 有 索引 ， 则 产生 表 锁 。 

' 主键 字段 不 具有 任何 业务 含义 ， 需 使 用 单一 字段 来 构建 。 主 键 的 变化 通常 是 由 于 其 具有 业务 含义 的 ， 比 如 用 电话 号 码 作为 主键 ， 其 修改 将 是 不 可 避免 的 。 如 果 保 证 了 主键 是 不 具有 任何 业务 含义 的 
话 ， 再 选择 复合 主键 就 没有 丝毫 意义 了 。 

“主键 的 唯一 作用 应 该 是 作为 表 与 表 的 关联 ， 不 应 该 出 现在 任何 WHERE 子 句 的 过 滤 条 件 中 。 

“ 主键 字段 尽 可 能 使 用 YS_GUID 方 式 蔡 代 SEQUENCE 方 式 ， 不 得 不 用 SEQUENCE 的 时 候 ， 应 该 使 用 “字符 十 SEQUENCE” 拼 接 的 方式 蔡 代 单纯 使 用 SEQUENCE 的 方式 ， 以 避免 发 生 主键 索引 叶 块 分 


裂 争 用 。 


首先 应 该 关注 的 是 主键 尽 可 能 避免 包含 业务 含义 ， 否 则 接 下 来 的 一 些 优化 手段 都 将 没有 意义 。 因 为 主键 一 旦 确定 ， 就 是 不 能 修改 的 ， 或 者 说 是 不 能 轻易 修改 的 ， 所 以 在 表 的 设计 阶段 必须 明确 业务 关 
系 ， 确 定 主键 字段 的 合理 选择 。 很 遗憾 的 是 ， 我 们 没 办 法 保证 业务 不 变 ， 因 此 避免 业务 的 改变 对 主键 的 影响 ， 则 需要 让 主键 和 业务 含义 独立 开 来 。 当 然 ， 对 于 一 些 没 有 太 大 变化 的 基 表 和 元 数据 表 ， 主 键 包 


含 业务 含义 是 无 可 厚 非 的 。 


对 于 主键 字段 尽 可 能 使 用 SYS_GUID 方 式 的 说 法 ， 可 能 很 多 人 并 不 赞成 ，SYS_GUID 的 VARCHAR (32) 甚至 可 能 被 认为 是 存储 空间 的 浪费 。 这 种 说 法 是 有 些 道理 的 ， 对 于 习惯 了 SEQUENCE 做 主键 的 
人 来 说 ， 一 下 要 接受 SYS_GUID 是 不 容易 的 ， 但 如 果 受 到 过 高 并 发 折磨 的 人 ， 接 受 起 来 就 比较 容易 一 些 了 。 如 果 表 的 宽度 本 身 就 很 宽 ，VARCHAR (32) 是 能 够 接受 的 ， 那 么 SYS_GUID 是 不 错 的 选择 ; 如 果 


表 本 身 就 不 宽 ， 为 了 减少 空间 浪费 和 不 必要 的 性 能 损耗 ， 可 以 使 用 “字符 + SEQUENCE”。 


， 避 免 分 裂 过 于 集中 。 这 里 就 不 做 实例 分 析 了 ， 具 体 的 分 析 方 法 可 以 参考 上 一 章 关 于 索引 分 裂 


使 用 SYS_GUID 或 者 “字符 + SEQUENCE” 的 原理 和 使 用 反 键 索引 是 一 样 ， 都 是 尽 可 能 分 散 索引 块 的 
的 实例 分 析 情 况 。 


3.2.4 LOB 字 段 


说 到 LOB 字 段 的 使 用 ， 在 实际 生产 应 用 中 ， 很 少 有 人 会 将 一 些 文件 放 在 数据 库 中 保存 ， 更 多 的 人 会 选择 用 文件 服务 器 保存 文件 ， 在 数据 库 中 存放 一 个 文件 地 址 。 但 是 ， 这 并 不 代表 LOB 字 段 就 没有 生命 
力 了 ， 相 反 ，LOB 字 段 在 很 多 系统 中 ， 还 是 得 到 了 广泛 的 使 用 ， 主 要 表现 为 CLOB 类 型 字段 对 大 文本 的 存储 。 什 么 样 的 文本 算是 大 文本 呢 ? CHAR 和 VARCHAR2 类 型 存储 不 下 的 文本 都 算是 大 文本 了 ， 此 时 就 


需要 使 用 LOB 类 型 的 字段 来 存储 了 。 


在 Oracle 119 之 后 ，LOB 字 段 有 了 两 种 存储 方式 : 基本 文件 (BasicFile) 和 安全 文件 (SecureFile) 。 在 119 版 本 之 前 ， 都 是 BasicFile 的 存储 方式 ， 这 种 传统 的 存储 方式 有 两 个 比较 大 的 弊端 : 


“ 高 并 发 处 理 能 力 差 。 


SecureFile 存 储 方式 的 引进 很 大 程度 上 是 为 了 解决 这 两 个 问题 。 本 书 中 ， 我 们 关注 的 重点 将 是 对 高 并 发 处 理 能 力 的 改善 。 可 能 有 人 会 说 是 因为 SecureFile 引 进 了 字段 压缩 和 字段 去 重 的 机 制 ， 其 高 并 发 处 
理 能 力 才 得 以 加 强 。 实 际 情况 却 并 非 如 此 ， 高 并 发 的 增强 主要 是 其 存储 机 制 的 改变 。 


1.LOB 结 构 DUMP 分 析 


从 数据 块 DUMP 的 日 志 来 比较 一 下 ， 可 以 看 到 在 11g 中 ，BasicFile 的 存储 方式 也 做 了 一 些 信息 的 扩展 ， 可 以 更 明确 地 看 到 LOB 字 段 的 存储 情况 。 单 从 SecureFile 的 日 志 来 看 ， 其 结构 较 BasicFile 似 乎 更 简 
单 了 ， 事 实 上 也 确实 如 此 ，SecureFile 在 数据 块 组 合 和 寻 址 方式 上 针对 高 并 发 争 用 的 场景 做 了 相当 程度 上 的 优化 。 


(1) 11g 数 据 库 BasicFile 存 储 的 LOB 


tab 0, row 0, Q@Oxlefa 


th: 103 Eh =H-Flm= I tel ons 


al 0 [2 CL 愉 


3 


col 1: [11] 6€1 6c 65 78 30 31 2e 64 6f 63 78 


col 2: [84] 


00 54 00 01 01 0c 00 00 00 01 00 00 00 01 00 00 00 ac 75 3d 00 40 05 00 00 
00 00 0c la a0 00 00 00 00 00 02 3b 80 00 85 3b 80 00 86 3b 80 00 87 3b 80 
00 83 3b 80 00 84 3b 80 00 96 3b 80 00 97 3b 80 00 91 3b 80 00 92 3b 80 00 
93 3b 80 00 94 3b 80 00 95 


LOB 

Locator: 
Length: 84(84) 
Version: 工 
Byte Length: 二 


LobID: 00.00.00.01.00.00.00.ac.75.3c 
Flags[ 0x01 0x0c 0x00 0x00 ]: 


Type: BLOB 
Storage: BasicFile 


Enable Storage in Row 
Characterset Format: IMPLICIT 


Partitioned Table: No 
Options: ReadWrite 
Inogde: 
Size: 64 
Flag: 0x05 [ Valid InodeInRow (ESIR) ] 
Future: 0x00 (should be '0x00') 
Blocks: 12 
Bytes: 6816 


Version: 00000.0000000002 


DBA Array[12]: 


0x3b800085 0x3b800086 0x3b800087 0x3b800083 
0x3b800084 0x3b800096 0x3b800097 0x3b800091 
0x3b800092 0x3b800093 0x3b800094 0x3b800095 


(2) 11g 数 据 库 SecureFile 存 储 的 LOB 


tab 0, row 0, @Oxlf2d 
tl: 58 fo -=H-FL-~— 1]h: 
oo QL 2 


Dxl ee: 


3 


col 1: [11] 6€1 6c 65 78 30 31 2e 64 6f 63 78 


ol 2: [39] 


00 54 00 01 01 0c 00 80 00 01 00 00 00 01 00 00 00 ac 77 £5 00 13 40 90 00 
0d 22 00 01 97 do 01 00 02 3b 80 00 91 0d 


LOB 

Locator: 
Length: 84(39) 
Version: 去 
Byte Length: 1 


LobID: 00.00.00.01.00 

Flags[ 0x01 0x0c 0x00 
Type: BLOB 
Storage: SecureFile 


Characterset Format: 


"00.00.ac.77.£5 


0x80 ]: 


IMPLICIT 


Partitioned Table: No 


Options: ReadWrite 
SecureFile Header: 
Length: 19 


Old Flag: 0x40 [ SecureFile ] 
Flag 0: 0x90 [ INODE Valid ] 


Layers: 


Lengths Array: INODE:13 


INODE: 


22 00 01 97 da0 01 00 02 3b 80 00 91 0d 


2.LOB 物 理 结构 剖析 


同样 先 来 看 一 下 BasicFile 的 情况 ， 如 图 


3-8 所 示 ， 在 默认 的 Enable Storage in Row 的 模式 下 ，BasicFile 的 LOB 列 中 ， 存 放 着 两 个 Layer Locator Layer (20 字 节 ) 和 lnode Layer (16 字 节 ) 。Locator 


包括 了 控制 信息 和 10 字 节 的 LOB ID，in-line 存 储 的 情况 下 包含 实际 的 LOB 数 据 (最 大 3964 字 节 ) ，out-of-line 存 储 的 情况 下 ， 至 多 包含 12 个 4 字 节 关联 DBAs (参见 上 述 DUMP 日 志 ) 。 如 果 LOB 过 大 ,将 
Locator 包 含 的 LOB ID 指向 LOB index 来 寻找 数据 CHUNKS (固定 大 小 ) ， 并 且 通 过 LOB index 结 构 来 实现 CHUNKS 的 读 取 一 致 性 。 


使 


Enable storage In row in-line LOB: 


LOB LOCATOR LOB INODE DATA 


20 字 节 16 学 节 最 大 3964 字 节 


Enable storage in row out-of-line LOB: 


LOB LOCATOR 
20 字 节 


LOB INODE 数据 指针 
16 字 节 0~48 字 节 (12 x RDBA) 


FT 
CEUNE CHUNK 
国术 (em 


图 3-8 ”BasicFile 存 储 LOB 物 理 结 构 


在 BasicFile 的 LOB 中 ，CHUNK 的 大 小 是 一 定 的 ， 最 小 和 数据 库 的 数据 块 大 小 一 样 ， 最 大 为 32KB。 在 CHUNKtHLOB 的 数据 小 很 多 的 情况 下 ， 访 问 LOB 就 会 产生 很 多 I/O， 而 在 CHUNKtHELOB 的 数据 大 很 
多 的 情况 下 ， 又 会 产生 对 存储 空间 的 浪费 。 


在 SecureFile 的 LOB 列 中 ， 如 图 3-9 所 示 ， 也 存放 着 Locator Layer 和 lnode Layer。Locator 的 内 容 和 BasicFile 里 是 一 样 的 。 而 Inode Layer 包 含 了 RCI Header 和 Inode 部 分 ， 其 中 Inode 部 分 包含 了 指向 
LOB 数 据 CHUNK 的 指针 ， 同 时 实现 了 如 普通 数据 块 一 样 的 UNDO， 减 少 了 对 LOB index 的 依赖 。 (RCI 即 表 段 里 存储 的 LOB 列 的 所 有 数据 ，RCI Header 里 存储 的 是 SecureFile 的 LOB 控 制 信息 。) 


Enable storage im row in-line LOB: 


LOB LOCATOR LOB INODE DATA 


20 字 节 16 字 节 最 大 3964 字 节 


Enable storage in row out-of-line LOB: 


CHUNK | CHUNK | 
LOB LOCATOR da | CHUNK | 
20 字 节 RCI Header le 


图 3-9 ”SecureFile 存 储 LOB 物 理 结 构 


在 SecureFile 中 ，CHUNK 的 大 小 是 可 变 的 ， 由 Oracle 自 动 动态 分 配 ， 最 小 跟 数据 库 的 数据 块 大 小 一 样 ， 最 大 为 64MB。 这 样 在 存储 较 小 的 LOB 时 ， 使 用 比较 小 的 CHUNK; 在 存储 比较 大 的 LOB 时 ,会 
使 用 比较 大 的 CHUNK。 注 意 不 是 说 一 个 LOB 就 放 在 一 个 CHUNK 里 ， 而 是 Oracle 根 据 LOB 的 数据 大 小 会 自动 决定 CHUNK 数 和 CHUNK 的 大 小 。 


如 上 所 述 ， 在 LOB 数 据 的 存储 方式 上 ， 两 种 LOB 有 很 大 的 区 别 。BasicFile 的 存储 方式 不 可 避免 地 会 产生 LOB index 竞 争 ， 成 为 瓶颈 。 


在 SecureFile 中 ，LOB index 只 有 在 使 用 重复 消除 功能 时 才 会 使 用 。 简 而 言 之 ，SecureFile 中 只 要 不 使 用 重复 消除 功能 就 没 LOB index 什 么 事 ， 自 然 高 并 发 处 理 能 力 就 上 去 了 。 


在 表 设 计 和 字段 选择 的 阶段 ， 比 较 好 的 做 法 是 在 Oracle 11g 之 前 的 版 本 中 ， 尽 可 能 避免 使 用 LOB 字 段 ， 不 得 不 使 用 的 时 候 ， 也 尽 可 能 避免 高 并 发 场景 使 用 。 而 在 119 及 之 后 版 本 中 ， 大 可 放心 使 
SecureFile 来 存储 LOB 字 段 ， 当 然 也 需要 留意 一 些 BUG 的 问题 。 


具体 案例 可 以 参考 第 5 章 中 介绍 的 LOB 争 用 问题 解决 方案 。 


3.3 ”字段 顺序 


字段 顺序 ， 这 个 问题 很 可 能 被 忽略 ， 但 是 它 的 影响 却 是 不 小 的 。 我 们 在 设计 一 个 表 的 字段 顺序 的 时 候 ， 往 往 会 有 些 随心 所 欲 ， 只 要 覆盖 了 所 有 的 业务 需求 不 就 好 了 么 ， 在 前 在 后 问题 也 不 大 嘛 。 业 务 扩 
展 导 致 字段 扩展 的 问题 ， 在 初期 的 设计 中 也 容易 被 忽视 ， 一 些 重要 字段 不 得 不 排 到 很 后 面 ， 甚 至 在 审计 字段 后 面 。 这 些 不 注意 和 被 忽视 ， 都 可 能 会 导致 性 能 问题 和 高 并 发 相关 问题 。 


我 们 在 这 里 先 提出 两 个 观点 ， 再 具体 展开 验证 。 
“ 较 热 〈 关 键 ) 的 字段 尽 可 能 靠 前 排 ; 


“ 最 小 化 行 宽 需要 严格 控制 ， 盲 目 大 方 是 不 可 取 的 。 


3.3.1 ” 热 字 段 靠 前 排 


在 开始 研究 字段 顺序 之 前 ， 先 来 了 解 一 下 数据 行 的 结构 吧 。 在 绝 大 多 数 RDBMSs 中 ， 除 了 一 些 专门 用 于 数据 分 析 等 特殊 功能 的 列 式 数据 库 外 ， 都 是 以 行为 单位 进行 存储 的 。 在 Oracle 数 据 库 中 ， 数 据 块 是 
最 小 的 存储 逻辑 结构 ， 而 数据 块 中 存储 的 数据 都 是 以 行为 单位 组 织 起 来 的 ， 每 一 个 存储 条 目 就 是 一 个 数据 行 。 


数据 行 的 结构 如 图 3-10 所 示 ， 从 左 到 右 的 顺序 ， 首 先 会 有 一 个 行头 ， 记 录 该 行 基础 信息 数据 ， 其 次 是 各 个 列 的 数据 ， 包 含 该 列 的 长 度 信息 和 实际 存储 的 数据 。 如 下 新 建 一 张 表 alex_t34: 


SQL> create table alex t34 ( 
coll varchar2 (1000 
Col2 varchar2( 
col3 varchar2( 
col4 varchar2 (1000 
col5 varchar2( 
col6 varchar2( 


oo mwm 必 wwN 


对 于 表 alex_t34 来 说 ，COL1 到 COL6 将 按照 从 左 到 右 的 顺序 依次 存储 在 行 结构 中 ， 也 就 是 说 越 靠 前 新 建 的 列 在 行 结构 中 就 越 靠 左 。 


+ mmT 7 " ' 
COLI1 COLI1 数 据 COL2 COL3 COL6 


长 度 | | “LO 和 和 


图 3-10” 行 结构 示意 图 


那 左 右 之 分 会 影响 到 性 能 吗 ? 当然 会 ， 数 据 库 引 擎 是 不 知道 行 结构 中 各 个 列 的 偏 移 量 的 ， 它 必须 从 左 到 右 逐 一 扫描 过 去 ， 越 是 靠 右 的 列 ， 寻 址 时 间 就 越 长 。 这 一 特点 与 磁盘 的 寻 道 是 有 些 类 似 的 。 


也 许 有 人 会 说 ， 这 一 点 点 差异 算 不 了 什么 的 吧 ? 好 吧 ， 如 果 能 接受 的 话 ， 那 也 不 必 多 说 的 。 但 是 面临 高 并 发 压力 的 系统 就 不 得 不 关注 这 一 细节 问题 了 ， 下 面 我 们 通过 一 个 实例 来 说 明 一 下 吧 。 


步骤 1 插入 1 万 行 记录 到 表 alex_t34 中 ， 每 行 记录 的 每 个 列 的 数据 都 是 完全 一 样 的 : 


SQL> declare 
2 begin 
六 for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/OEBPSVText/. . 10000 loop 


4 insert into alex t34 
号 values 
6 (rpad('alex', 1000, ' '), 
7 rpad('alex', 1000, ' '), 
8 rpad('alex', 1000, ' '), 
9 rpad('alex', 1000, ' '), 
10 rpad('alex', 1000, ' '), 
为 rpad('alex', 1000, ' ')) 
12 end loop; 
13 commit 
14 end; 


步骤 2 针对 表 的 第 一 列 和 最 后 一 列 求 count () ， 上 比较 


响应 时 间 ， 为 了 方便 差异 比较 ， 循 环 执行 1000 次 : 


SQL> declare 
cnt number; 
begin 
for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 1000 loop 
select count (col1) into cnt from alex t34; 
end loop; 
commit; 
end; 


oOANAOD 


Elapsed: 00: 00: 45.91 
SQL> declare 
cnt number; 
begin 
for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 1000 loop 
select count (co16) into cnt from alex t34; 
end loop; 
commit; 
eng; 


oonAOND 


/ 
Elapsed: 00: 00: 58.86 


从 执行 结果 看 到 ， 对 col6 的 查询 比 col1 的 查询 慢 了 很 多 ， 如 果 并 发 度 高 的 话 ， 这 样 的 差距 会 更 大 。 再 看 表 alex_t34 的 结构 ， 行 宽 为 6000 个 字 节 ， 并 没有 超出 一 个 数据 块 的 限制 ， 说 明 本 次 的 查询 是 在 一 
个 数据 块 中 完成 的 ， 并 没有 行 链接 的 干扰 。 


基于 以 上 的 原因 ， 一 般 表 设计 的 规范 应 该 是 将 可 能 频繁 访问 的 字段 放 在 前 面 ， 同 时 在 返回 数据 的 时 候 ， 不 要 使 用 “SELECT *” 这 样 的 写法 ， 只 选择 返回 需要 的 字段 ， 避 免 访问 比较 靠 后 的 非 必要 字段 。 
对 于 NULL 值 的 列 则 尽量 往 后 排 ， 因 为 对 于 最 后 的 NULL 列 ，Oracle 是 不 会 进行 存储 的 。 


值得 多 提 一 下 的 是 ， 对 于 count () 取 值 的 时 候 ， 尽 可 能 也 需要 靠 前 的 列 ， 当 然 使 用 虚拟 列 效果 将 会 更 好 一 些 。 以 上 的 测试 我 们 扩展 一 个 步骤 来 看 看 : 


步骤 3 将 count (col1) 替换 成 count (1) ， 循 环 执行 1000 次 : 


SQL> declare 
2 cnt number; 
3 begin 


for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 1000 loop 
select count (1) into cnt from alex t34; 


4 

5 

6 end loop; 
7 commit; 

8 end; 

9 7 

Elapsed: 00: 00: 45.61 


测试 结构 可 以 看 到 ， 虚 拟 列 求 count () 效果 更 好 一 些 。 


3.3.2 行 宽 需 要 控制 


我 们 了 解 到 了 行 结构 的 存储 方式 ， 知 道 比较 靠 后 的 列 在 取 值 返 回 的 时 候 ， 性 能 比较 差 ， 也 就 是 说 行 结构 中 越 靠 后 的 位 置 ， 访 问 效率 就 越 差 。 同 样 的 道理 ， 如 果 一 个 或 几 个 列 言 目地 设置 为 很 长 的 长 度 ， 
那么 行 结构 的 访问 位 置 也 将 后 移 ， 效 率 也 会 受到 影响 。 


我 们 再 进行 一 个 实例 来 分 析 对 比 一 下 看 看 吧 。 


步骤 1 新 建 一 个 与 alex_t34 类 似 的 表 alex_t35， 只 是 每 个 列 的 宽度 从 1000 缩 小 到 100: 


SQL> create table alex t35 ( 
coll varchar2(100), 
Col2 varchar2( ys 
col3 varchar2( bp 
col4 varchar2(100), 
col5 varchar2( ; 
(100) 


col6 varchar2 (100 


oam 必 mwN 


步骤 2 清空 alex_t34 后 ， 同 样 给 alex_t35 和 alex_t34 插 入 1 万 条 记录 ， 每 行 每 列 存储 一 样 的 数据 : 


SQL> declare 


for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 10000 loop 


2 begin 

3 

4 insert into alex t34 
5 values 

6 (rpad('alex', 100, ' 
7 rpad('alex', 100, ' 
8 rpad('alex', 100, ' 
9 insert into alex t35 
10 values 加 

11 (rpad('alex', 100, ' 
12 rpad('alex', 100, ' 
13 rpad('alex', 100, ' 
14 end loop; 

15 commit; 

16 end. 

17 .4 


'), rpad('alex', 100, 
'), rpad('alex', 100, 
'), rpad('alex', 100, 


, rpad('alex', 100, 
'), rpad('alex', 100, 
7 


rpad('alex', 100, ' 


步骤 3 ”针对 表 的 最 后 一 列 求 count 


() ， 循 环 执行 1000 次 ， 


比较 其 响应 时 间 : 


SQL> declare 
cnt number; 
begin 


end loop; 
commit; 
end; 


oOIANAON 


/ 
Elapsed: 00: 00: 07.82 
SQL> declare 
cnt number; 
begin 


end loop; 
commit; 
end; 


oOANAOD 


/ 
Elapsed: 00: 00: 06.22 


从 响应 时 间 来 看 ， 表 alex_t35 比 表 alex_t34 的 返回 


速度 快 了 25%， 可 见 列 宽 对 性 能 的 影响 程度 之 大 。 对 于 一 个 表 的 设计 来 说 ， 控 制 行 宽 是 非常 必要 的 ， 严 格 控制 ， 避 免 盲目 的 大 方 ， 能 F 


for i in lhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/..1000 loop 
select count (co16) into cnt from alex t34; 


for i in lhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/OEBPSVText/. .1000 loop 
select count (co16) into cnt from alex t35; 


varchar2 (100) 存储 的 ， 坚 决 不 用 varchar2 (1000) 来 存储 。 不 是 说 VARCHAR2 类 型 的 字段 是 可 变 字 段 ， 长 的 就 可 以 随意 放大 一 些 ， 这 其 实 是 一 种 会 引发 高 并 发 性 能 问题 的 隐患 。 


从 另 一 方面 来 看 ， 对 于 行 宽 需 要 控制 在 一 定 范围 


@ 担 示 “在 字段 的 排列 和 长 度 控制 也 需要 精打细算 ， 吉 免 言 目 大 方 。 


3.4，” 行 链接 与 行 迁移 


内 ， 保 证 一 行 的 数据 能 够 被 完全 存储 在 一 个 数据 块 中 也 是 非常 必要 的 ， 防 止 行 链接 的 问题 在 下 一 节 的 行 链接 原理 中 会 展开 讨论 。 


在 表 的 设计 和 后 期 性 能 优化 阶段 ， 往 往 最 容易 被 忽视 甚至 无 视 的 就 是 表 的 行 长 相关 问题 ， 集 中 表现 在 行 链 接 和 行 迁移 上 。 在 设计 阶段 ， 主 要 是 行 长 过 长 ， 造 成 后 期 发 生 行 链接 的 问题 ;在 使 用 和 维护 阶 
段 ， 则 常常 因为 一 些 更 新 操作 导致 行 迁移 问题 。 


“ 行 链 接 ” 和 “ 行 迁移 ”其 实 是 两 个 完全 不 一 样 的 概念 ， 但 是 在 Oracle 的 诊断 过 程 中 ， 却 没有 明显 地 区 分 开 ， 导 致 不 少 人 对 这 两 个 概念 的 混淆 ， 误 认为 是 一 个 概念 ， 或 者 两 者 的 概念 完全 颠倒 过 来 。 我 
在 实际 案例 中 ， 曾 经 也 遇 到 过 不 少 资深 和 人员 同 样 会 发 生 混淆 ， 造 成 误导 。 


3.4.1 行 链接 原理 


先 来 说 说 行 链接 吧 。 我 们 知道 数据 块 是 数 
据 块 不 足以 存储 一 行 记录 的 时 候 ， 那 么 Oracle 会 分 配 一 个 新 块 来 存储 第 一 个 块 存储 不 下 的 部 分 ， 如 图 3-11 所 示 ， 此 时 就 产生 了 行 链接 。 


此 时 ， 如 果 我 们 需要 查询 行 01 记 录 中 的 A、B 两 列 ， 很 幸运 地 发 现 ， 这 两 列 都 存储 在 第 一 个 块 ， 我 们 只 需要 扫描 第 一 个 


居 存 储 的 最 小 逻辑 和 


元 ， 表 中 的 数据 都 是 需要 存储 在 某 个 或 某 几 个 数据 块 中 的 ， 但 是 数据 块 都 是 有 一 定 大 小 的 (默认 大 小 为 8K) ， 进 行 插入 操作 时 ， 当 一 个 数 


有 了 额外 的 MO 开销 ， 也 就 是 产生 了 行 链接 。 这 是 不 是 从 另 一 个 角度 告诉 我 们 ， 关 键 字段 需要 尽量 往 前 放 ? 


行 链接 在 数据 产生 的 时 候 就 存在 了 ， 它 就 在 那里 不 变 不 移 ， 除 非 删除 。 


块 ， 避 免 了 额外 的 块 扫描 。 但 如 果 需 要 查询 的 是 D、E 列 ， 则 需要 扫描 两 个 块 了 ， 


因此 ， 要 消除 行 链接 的 隐患 ， 就 要 在 表 的 设计 之 初 考虑 到 。 假 设 数据 块 大 小 为 默认 的 8192 字 节 ，PCTFREE 为 10%， 那 么 行 长 最 多 


为 多 少 呢 ? 应 该 是 8192 字 节 减 去 预 留 的 192 字 节 ， 再 乘 以 90%， 约 为 7200 字 节 。 实 际 使 用 尽量 控制 在 7000 字 节 以 内 。 值 得 注意 的 是 ， 这 个 7000 字 节 并 不 是 表 定义 的 字段 总 长 ， 而 是 表 实际 存储 的 字段 总 
长 ， 比 如 : VARCHAR2 (100) 存储 的 字段 最 大 为 60 字 节 长 ， 那 计算 该 字段 长 就 需要 计算 为 60 字 节 ， 而 非 100 字 节 。 


接 下 来 再 深入 思考 一 下 ， 行 链接 有 什么 影响 呢 ? 如 果 说 是 查询 时 扫描 的 块 数 变 多 了 ， 那 确实 有 那么 多 数据 啊 ， 需 要 两 个 数据 块 存 储 的 数据 在 不 改变 数据 块 大 小 的 前 提 下 ， 怎 么 也 不 可 能 存储 到 一 个 里 面 
去 的 。 如 果 说 是 后 置 列 查询 时 会 产生 额外 数据 块 的 扫描 ， 那 就 算 我 们 将 其 分 拆 成 两 个 表 ， 再 通过 表 的 联 立 来 查询 ， 那 开销 将 会 更 大 。 同 时 ， 需 要 注意 的 是 ， 查 询 操作 不 论 是 全 表 扫 描 ， 还 是 索引 扫描 ， 行 链 
接 的 影响 同样 是 存在 的 。 


是 不 是 行 链接 的 问题 就 没 办 法 消除 呢 ? 不 是 的 。 我 们 在 设计 阶段 还 是 要 从 业务 需求 出 发 ， 明 确 每 个 字段 是 否 必要 ， 是 否 控制 在 必要 的 最 小 长 度 (这 方面 需要 足够 的 音 甫 ) 。 如 果 严 格 的 控制 ， 行 链接 问 
题 自然 不 会 存在 。 值 得 注意 的 是 ， 谁 都 不 能 保证 一 个 表 是 否 需 要 增加 字段 ， 所 以 需要 尽 可 能 考虑 到 行 长 的 元 余 。 反 之 ， 业 务 确实 需要 足够 的 行 长 ， 那 就 应 该 考虑 使 用 较 大 的 数据 块 。 


还 有 一 种 比较 特殊 的 行 链接 ， 它 是 发 生 在 一 个 数据 块 上 的 ， 这 又 是 怎么 回 事 呢 ? 因为 Oracle 数 据 库 的 引擎 无 法 在 一 行 记录 中 保存 超过 255 个 字段 的 数据 。 如 果 有 超过 255 个 字段 ， 将 被 分 拆 成 多 个 片段 分 
别 存储 ， 如 图 3-12 所 示 ， 就 会 出 现 一 个 数据 块 中 存储 了 某 一 行 记 录 的 两 个 片段 ， 在 单 块 内 出 现行 链接 。 这 种 现象 称 为 “ 块 内 行 链接 ”， 也 是 需要 在 设计 阶段 严格 控制 的 。 


PCTFREE PCTFREE 


图 3-11 行 链接 示意 图 


图 3-12 块 内 行 链接 示意 图 


@ia 示 行 链接 产生 于 插入 或 更 新 操作 ， 在 全 表 扫 描 查 询 和 索引 扫描 查询 中 都 会 产生 影响 ， 其 需要 在 设计 阶段 严格 控制 ， 控 制 字段 数量 ， 并 避免 不 必要 的 大 字段 扩展 。 


3.4.2 ，” 行 迁移 原理 


我 们 在 设计 阶段 杜绝 了 行 链接 的 产生 ， 接 下 来 就 需要 在 使 用 和 维护 阶段 避免 行 迁移 的 产生 了 。 当 一 行 记录 上 发 生 UPDATE 操 作 ， 原 有 存储 的 数据 有 增 无 减 ， 则 导致 当前 的 数据 不 能 再 容纳 在 当前 块 ， 我 


们 需要 进行 行 迁 


原 有 块 上 。 


移 。 如 


3-13 所 示 ， 同 样 一 行 记录 被 分 拆 成 两 个 片段 ， 分 别 存 储 在 不 同 的 两 个 数据 块 上 ， 与 行 链接 有 所 不 同 的 是 ， 一 次 行 过 


移 意味 着 整 行 数据 将 会 移动 ， 仅 仅 保留 的 是 一 个 转移 地 址 指针 在 


数据 块头 


PCTFREE 


图 3-13” 行 迁移 示意 图 


与 行 链接 相 比 ， 行 迁移 是 更 加 需要 引起 注意 的 。 因 为 行 链接 在 设计 阶段 严格 控制 还 是 可 以 杜绝 的 ， 而 行 迁 移 则 不 然 ， 我 们 很 难 去 控制 实际 业务 的 更 新 行为 ， 从 某 种 意义 上 来 说 ， 行 迁移 是 不 可 能 被 杜绝 
的 ， 只 能 尽 可 能 地 控制 少 发 生 。 


行 迁移 是 如 何 影响 性 能 的 呢 ? 主要 从 表 的 访问 路 径 为 出 发 点 来 考虑 ， 如 果 是 进行 全 表 扫 描 ， 是 不 会 被 行 迁移 所 累 的 ， 因 为 片段 1 中 是 没有 数据 的 ， 会 直接 被 跳 过 ， 直 接 访问 片段 2 中 的 数据 ， 或 者 说 全 部 
数据 块 被 扫描 ， 块 与 块 之 间 的 行 迁移 链 被 无 视 了 ;如果 是 进行 ROWID 扫 描 (索引 扫描 ) ， 获 取 的 ROWID 指 向 的 是 片段 1， 再 通过 片段 1 中 的 指针 链接 到 片段 2， 这 样 就 势必 受到 行 迁移 的 影响 ， 严 重 时 这 样 
的 开销 将 会 翻 倍 。 


一 套 设计 比较 好 的 系统 ， 行 链接 基本 上 是 不 大 可 能 会 出 现 的， 更 多 的 是 出 现行 迁移 的 问题 。 我 曾经 处 理 过 一 个 数据 库 的 核心 表 ， 有 干 万 级 的 数据 行 ， 其 中 20% 的 数据 行 发 生 了 行 迁移 ， 这 就 是 个 比较 坊 
手 的 问题 了 。 试 想 一 下 ， 一 个 核心 表 会 有 多 少 查 询 是 通过 全 表 扫 描 进行 的 呢 ? 可 以 说 没有 ， 基 本 上 都 是 通过 索引 扫描 ROWID 的 访问 形式 ， 问 题 就 出 现 了 。 


Os 更 新 操作 触发 行 迁移 ， 在 实际 使 用 过 程 中 ， 行 迁移 的 危害 往往 要 远大 于 行 链接 造成 的 危害 ， 特 别 是 对 于 核心 表 ， 应 该 定期 的 检查 行 迁移 的 情况 。 


3.4.3 ”发 现 问题 


行 链接 和 行 迁移 都 会 带 来 行 级 锁 的 额外 开销 ， 每 一 个 片段 都 需要 持 有 锁 ， 片 段 越 多 ， 产 生 的 额外 开销 也 将 会 越 高 ， 对 于 数据 块 来 说 ， 其 热点 争 用 发 生 的 可 能 性 也 将 越 大 。 上 面 说 到 的 20% 记 录 发 生 行 迁 
移 的 核心 表 ， 基 本 上 数据 库 上 所 有 的 业务 应 用 都 会 使 用 到 该 表 ， 正 常情 况 下 的 并 发 量 已 经 很 大 了 ， 如 果 因 为 行 迁移 导致 行 级 锁 的 争 用 等 待 ， 其 并 发 处 理 能 力 将 会 严重 下 降 ， 甚 至 会 拖累 整个 数据 库 和 业务 系 
统 的 正常 使 用 。 


这 就 督促 我 们 要 及 时 发 现行 迁移 的 问题 ， 主 动 地 去 预防 ， 解 决 这 个 问题 隐患 。 


行 迁移 和 行 链接 的 处 理 方式 和 解决 其 他 问题 不 一 样 ， 它 的 思路 可 能 更 像 是 判断 索引 是 否 需要 重建 ， 因 为 解决 问题 不 难 ， 手 段 也 不 多 ， 但 是 发 现 问题 确 是 挑战 。 从 Oracle 提 供 的 方法 来 看 ， 我 们 只 能 通过 
分 析 表 来 获取 哪些 行 是 发 生 了 行 迁 移 或 行 链接 的 ， 该 分 析 方式 是 无 法 区 别 行 链接 和 行 迁移 的 ， 应 该 说 如 果 不 进行 数据 块 的 DUMP 分 析 ， 是 无 法 确定 是 发 生 了 行 链接 还 是 行 迁移 的 。 不 过 ， 我 们 的 目的 是 解决 
问题 ， 是 行 链接 还 是 行 迁移 ， 我 们 不 必要 过 于 关心 。 


SQL> analyze table alex t05 list chained rows into chained rows; 


通过 分 析 表 ， 可 以 精准 地 知道 表 中 哪些 行 发 生 了 行 迁移 或 行 链接 ， 并 将 分 析 结 果 保 存 到 表 chained_rows 中 。 但 是 这 种 方法 开销 是 非常 大 的 ， 而 且 对 表 会 产生 锁 ， 分 析 的 过 程 中 ， 性 能 上 可 以 说 表 基本 上 
是 不 可 用 了 ， 特 别 是 对 于 以 上 说 到 的 核心 表 ， 那 将 是 “毁灭 ”性 的 。 


当然 ， 我 们 可 以 迁 回 解决 这 个 问题 ， 如 果 有 物理 Data Guard 库 (必须 在 行 迁移 发 生 之 前 就 存在 ) 的 话 。 相 同 的 分 析 操 作 在 Data Guard 的 Standby 库 上 进行 。 然 而 ，Standby 库 也 是 有 ; 
没有 谁 会 闲置 一 个 资源 在 Standby 库 上 ， 所 以 也 需要 权衡 这 样 的 分 析 是 否 值得 去 做 。 


特殊 作用 的 ， 


如 果 没 有 Standby 库 或 者 没有 闲置 的 standby 库 ， 那 么 下 面 将 介绍 一 种 比较 灵巧 的 方法 来 发 现 问题 。 


做 行 迁 移 和 行 链接 的 分 析 ， 对 于 整个 数据 库 或 者 某 个 SCHEMA 来 说 开销 是 很 大 的 ， 但 是 定位 到 某 个 表 或 某 几 个 表 之 后 ， 再 做 分 析 就 变 得 可 行 了 。 那 么 ， 关 键 的 问题 就 成 了 先 精准 定位 到 哪些 表 需 要 做 行 
迁移 和 行 链接 的 分 析 。 


首先 ， 以 统计 项 “table fetch continued row” 为 出 发 点 ， 在 数据 库 层 面 ， 发 生 一 次 行 迁 移 或 行 链接 扫描 的 影响 ， 该 值 就 会 增加 1。 如 果 表 上 存在 行 迁移 的 现象 ， 但 是 查询 不 经 过 ROWID 扫 描 ， 而 是 全 
表 扫 描 ， 则 “table fetch continued row” 不 会 增加 1。 结 合 考虑 统计 项 “table fetch by rowed” 和 “table scan rows gotten” 就 可 以 得 到 整个 数据 库 某 一 个 时 间 段 内 ROWID 扫 描 触 发 了 行 迁移 的 概率 
情况 和 发 生 行 迁移 或 行 链接 对 所 有 查询 的 占 比 情况 。 


其 次 ， 我 们 需要 借助 AWR 工 作 量 记录 的 快照 表 ， 抓 取 各 个 快照 阶段 统计 项 指标 的 数据 ， 并 进行 加 工 。 涉 及 的 统计 项 指标 如 下 : 


“ table fetch continued row: 发 生 行 链接 和 行 迁 移 的 返回 行 数 ; 
“ table fetch by towid: 发 生 ROWID 扫 描 的 返回 行 数 ; 


“ table scan rows gotten: 总 返回 行 数 。 


最 后 ， 我 们 可 以 得 到 两 个 比率 ， 行 迁移 率 = (发 生 行 链接 和 行 迁移 的 返回 行 数 /发 生 ROWID 扫 描 的 返回 行 数 ) x100%， 行 链接 率 = (发 生 行 链接 和 行 迁移 的 返回 行 数 /总 返回 行 数 ) x100%。 前 面 说 
到 ， 行 链接 在 设计 阶段 可 以 很 好 地 杜绝 ， 因 此 这 个 分 析 方法 主要 是 解决 行 迁移 的 问题 ， 重 点 考察 行 迁 移 率 的 大 小 。 请 注意 ， 这 个 行 迁 移 率 不 是 前 面 提 及 的 经 过 分 析 表 得 到 的 那个 行 迁移 率 ， 而 是 针对 ROWID 
扫描 (索引 查询 ) 操作 发 生 的 行 迁 移 率 。 其 实 ， 我 们 就 是 在 使 用 行 迁移 会 影响 AROWID 扫 描 的 结论 来 反 推 以 诊断 行 迁移 的 情况 。 如 果 某 些 表 发 生 了 行 迁移 ， 但 是 对 数据 库 没 什么 影响 ， 我 们 自然 不 必 理 会 它 ， 
该 诊断 方法 对 这 种 情况 不 敏感 。 


中 | 


此 方法 可 以 通过 以 下 脚本 来 实现 : 


select snap id， 
to_char (snap time, 'yyyy-mm-dd hh24:mi') snap time, 
V1 "table fetch continued row", 
V2 "table fetch by rowid", 


decode (v2, 0, 0, trunc(vl / v2 * 100, '2')) || '%' "chain to rowid scan(%)", 
V3 "table scan rows gotten", 
decode (v3, 0, 0, trunc(vl / v3 * 100, '2')) || '%' "chain to all scan(%)" 


from (select a.snap jd 
b.snap time, 
max (decode (a.stat name, 
'table fetch continued row', 
trunc (a.value / b.snap interval), 
0)) v1, 
max (decode (a.stat name, 
"table fetch by rowid', 
trunc (a.value / b.snap interval), 
0)) v2, > 
max (decode (a.stat_ name, 
"table scan rows gotten', 
trunc (a.value / b.snap interval), 
Oj} vw 
from (select snap id, 
stat name, 
decode (sign (value - lag(value, 1) 
over (partition by stat name order by 
snap id)), > 
下 一 
Valuey 
value - lag(value，1) 
over (partition by stat name order by snap id)) value 
from dba hist sysstat 
where stat name in 
('table fetch continued row', 'table fetch by rowid', 
"table scan rows gotten')) ay 
(select snap id 
snap time, 
trunc ( (snap time - lag (snap time) 
over (order by snap id)) * 24 * 60) snap interval 
from (select snap id 
to gate (to char (begin interval time, 
'yyyy-mm-dd hh24:mi:ss'), 
'yyyy-mm-dd hh24:mi:ss') snap time 
from dba hist snapshot 
where to char(begin interval time, 'yyyymmdd') between 
'&start yyyynrmdd' and Tg&end yyyymmdd')) b 
where a.snap id = b.snap id 
group by a.snap id, b.snap time) 
order by snap id; 


可 以 看 到 不 同 的 时 段 ， 行 迁移 率 (输出 结果 的 “chain to rowid scan (%) ” 栏 位 ) 产生 影响 的 概率 是 不 一 样 的 ， 我 们 就 可 以 对 应 概率 比较 高 的 时 段 ， 捕 获 TopSQL 就 能 有 效 地 定位 到 发 生 了 行 迁移 或 
行 链接 ， 并 且 影 响 到 数据 库 性 能 的 表 ， 然 后 有 针对 性 地 分 析 。 


SNAP_TIME table fetch continued row chain to rowid scan (村 ) 
2013-11-01 10:00 0 0% 

2013-11-01 10:10 474 3.4% 

2013=11=01 10:20 641 4.23% 

2013-11-01 10:30 49 0.47% 

2013-11-01 10:40 3051 9.83% 

2013-11-01 10:50 46 0.49% 

2013-11-01 11:00 158 -113% 


3.4.4 解决 问题 


问题 找到 了 ， 解 决 问题 我 们 还 是 需要 将 行 链接 和 行 迁移 分 开 来 看 的 。 


行 链接 ， 其 特点 是 易 避 免 ， 难 解决 。 行 链接 应 该 在 设计 阶段 严格 控制 ， 几 乎 没有 有 效 的 办 法 在 后 期 去 解决 ， 除 非 重新 建 模 。 避 免 的 方法 : 


' 控制 行 长 ， 黑 认 8192 字 节 的 数据 块 ， 控 制 行 长 在 7000 字 节 以 内 ; 


: 单 表 字 段 数 不 超过 255 个 ; 


“ 不 可 避免 的 时 候 ， 考 虑 使 用 较 大 的 数据 块 。 


行 迁移 ， 其 特点 则 是 难 避 免 ， 易 解决 。 行 迁移 的 处 理 重点 应 该 放 在 后 期 的 维护 上 ， 通 过 上 述 方法 有 效 定位 后 ， 可 以 通过 以 下 方法 解决 。 


(1) 行 级 的 细 粒 度 解决 方法 


分 析 表 后 获取 发 生 了 行 迁移 或 行 链接 的 ROWID， 将 相关 记录 复制 到 | 临时 表 后 ， 再 将 其 从 原 表 中 删除 ， 并 插入 临时 表 中 复制 的 记录 行 。 


该 方法 的 优点 是 针对 性 强 、 影 响 面 小 ， 缺 点 是 业务 离线 ， 遇 到 关联 性 强 的 表 几 乎 无 法 操作 。 


(2) 表 级 的 解决 方法 
“ 缩小 PCTFREE 参 数 ， 增 大 数据 块 可 用 空间 ; 
“ 通过 EXP/TIMP 或 者 EXPDP/IMPDP， 导 出 导入 数据 表 ; 


* ALTER TABLE MOVE; 


“ 表 在 线 重 定义 。 


以 上 四 种 方法 都 影响 整个 表 ， 而 且 都 无 法 保证 完全 在 线 完成 维护 操作 ， 这 里 就 需要 比较 各 


数据 库 ， 表 在 线 重 定义 将 会 是 一 个 不 错 的 选择 。 具 体 方法 请 参考 下 一 节 内 容 。 


也 许 有 人 会 问 到 ， 如 果 一 个 表 行 迁移 率 没 那 么 高 ， 那 整 张 表 的 
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说 到 


分 区 表 的 使 用 


Oracle 的 表 的 设计 ， 不 说 说 分 区 表 ， 似 乎 缺 了 点 什么 。 这 就 好 比 在 一 个 Oracle 数 据 库 中 不 建 几 个 分 


的 需要 分 区 表 吗 ? 


3 


先 来 讲 一 个 案例 吧 。 曾 经 被 咨询 过 一 个 分 区 表 使 
高 ， 需 要 对 该 表 进 行 改造 。 该 表 存储 的 是 全 国 各 地 分 公司 的 不 同 级 别 的 客 


何 时 使 用 分 区 表 


定义 ， 开 销 会 不 会 太 大 ? 那 是 不 是 可 以 


自 的 影响 面 了 。 第 二 种 和 第 三 种 方法 离线 时 间 较 长 ， 对 于 要 求 高 可 


性 的 系统 基本 上 不 


考虑 ， 对 于 高 并 发 的 


反问 一 下 ， 行 迁移 率 没 那么 高 ， 那 真 的 需要 处 理 吗 ? 


的 案例 ， 需 求 大 致 是 这 样 的 : 现 有 一 套 线 上 业务 系统 ， 主 体 业 务 围绕 着 一 个 50GB 的 大 表 ， 


比较 大 ， 


如 不 做 分 


RANGE 分 区 。 因 为 越 是 高 级 的 客户 ， 数 量 越 是 少 ， 


户 信息 (包括 高 级 客户 和 普通 客户 等 ) 。 然 而 ， 
其 他 城市 相对 数据 量 较 小 ， 也 就 是 说 数据 分 布 并 不 均匀 。 这 就 对 我 们 的 设计 思路 提出 了 挑战 。 
至 上 的 原则 ， 那 应 对 客户 进行 分 区 ， 来 保证 高 级 客户 更 大 的 权益 。 不 幸 的 是 ， 业 务 系统 的 增 、 删 、 改 、 查 都 是 通过 分 公司 


区 改造 。 此 时 ， 我 们 应 该 从 业务 需求 出 发 ， 按 分 公司 进行 LIST 分 区 。 因 


为 使 


通过 以 上 例子 的 介绍 ， 我 们 可 以 得 到 两 个 判断 原则 了 : 
“ 大 于 2GB 的 表 才 考 虑 分 区 ; 
“ 分 区 键 必须 反映 业务 需求 ， 增 、 删 、 


这 里 
表 扫 描 就 自然 转变 为 分 区 扫描 了 。 当 查询 返回 的 结果 集 超 过 表 的 总 数据 量 的 10% 时 ，Oracle 会 倾向 
对 于 已 经 使 


再 多 说 一 句 ， 对 于 以 上 的 案例 ， 如 果 能 通过 TABLE 级 、SCHEMA 级 、 数 据 库 级 来 物理 隔离 各 个 分 公司 


3.5.2 ”分 区 表 设 计 思 路 


我 们 说 一 切 设 计 的 思路 都 是 以 业务 需求 为 出 发 点 的 ， 但 是 也 需要 考虑 技术 层 


的 思路 ， 


分 区 的 设计 中 需要 特别 关注 数据 的 分 布 ， 尽 可 能 保证 数据 要 均匀 分 布 到 每 个 分 


分 区 键 不 能 被 经 常 UPDATE， 较 短 周期 内 UPDATE 的 记录 行 数 超过 10%， 该 字段 就 不 适合 做 分 


UPDATE 


分 区 键 尽 可 能 赋予 一 个 DEFAULT 值 ， 避 免 NULL 什 的 出 现 。 如 果 分 区 键 出 现 NULL， 会 被 抛 到 MAXVALUE 分 区 ， 


将 其 独立 到 一 个 子 分 


区 ， 性 能 更 优 。 


区 表 总 会 觉得 不 够 完美 ， 特 别 是 遇 到 一 些 比较 大 的 表 。 但 是 ， 我 们 实际 遇 到 的 问题 是 什么 呢 ， 真 


因为 业务 过 于 依赖 访 表 ， 导 致 查询 性 能 差 ， 并 发 处 理 能 力 不 


各 地 分 公司 的 业务 不 均衡 ， 


比如 : 上 海 、 北 京 、 杭 州 等 城市 业务 比较 突出 ， 数 据 量 


因为 该 表 足 够 大 ， 


压力 也 不 小 ， 是 可 以 考虑 做 分 区 表 的 ， 接 下 来 就 是 分 区 键 的 选择 了 。 如 果 依 据 客户 


来 隔离 的 ， 如 果 按 客 


户 来 分 区 的 话 ， 就 会 导致 过 多 的 跨 分 区 操作 ， 其 结果 可 能 还 不 
的 是 Oracle 119 数 据 库 ， 我 们 可 以 在 LIST 分 区 的 基础 上 创建 复合 分 区 ， 此 时 可 以 考虑 客户 权益 的 问题 ， 进 行 LIST- 


改 、 查 操作 基本 上 都 能 在 单个 分 区 完成 ， 尽 可 能 避免 跨 分 区 操作 。 


也 可 以 从 数据 生命 周期 管理 的 角度 来 判断 是 否 使 用 分 区 。 我 们 知道 ， 对 于 一 个 表 来 说 ， 往 往 不 可 避免 会 出 现 全 表 扫 描 的 情况 ， 如 果 通过 分 区 ， 
F 走 全 表 扫 描 ， 为 降低 I/O 


索引 并 且 结 果 集 较 小 的 情况 ， 做 分 区 不 一 定 能 提升 性 能 。 如 果 返 回 的 结果 集 有 一 定 的 数据 量 ， 能 将 查询 的 数 


据 量 集中 在 一 个 分 


的 数据 ， 那 将 比 使 有 


分 区 表 的 效果 更 优 。 


将 活跃 数据 、 亚 活跃 数据 、 历 史 数 据 有 效 隔 离 ， 则 全 


的 消耗 ， 可 考虑 做 分 区 。 


区 中 进行 扫描 ， 效 率 会 有 一 定 的 提高 。 


能 更 好 地 把 握 。 


， 可 能 意味 着 数据 从 一 个 分 区 迁移 到 另 一 个 ， 


分 区 数量 不 宜 过 多 ， 分 


3.5.3 ”分 区 表 特 性 


范围 分 区 (Range Partition) 通常 是 使 


区 越 多 维护 成 本 越 高 ， 管 理 越 复 杂 。 做 HASH 分 


面 的 实现 ， 必 要 的 时 候 ， 也 需 


业务 向 技术 看 齐 。 在 分 区 表 的 设计 上 也 是 如 此 ， 所 以 更 加 要 求 DBA 们 在 技术 层面 有 一 个 清 


区 ， 偏 大 或 偏 小 的 比例 控制 在 20% 以 内 ， 这 样 可 以 提高 效率 ， 尤 其 是 在 并 行 查询 时 。 


区 键 ， 因 为 当 数 据 的 10% 被 修改 后 ， 其 


这 样 的 开销 也 会 是 很 大 的 。 有 的 时 候 这 样 的 数据 跨 分 区 是 无 法 避免 的 ， 所 以 在 分 


区 的 时 候 ， 分 


频率 最 高 的 分 区 方式 ， 当 数据 可 以 被 均匀 地 划 


如 果 范 围 分 区 会 由 于 不 均等 的 划分 而 导致 分 区 在 大 小 上 明显 不 同时 ， 那 么 就 需 


范围 分 区 表 创 建 示例 如 下 : 


考虑 其 他 分 区 方法 。 


区 数量 必须 要 是 2 的 N 次 方 ， 


分 成 逻辑 范 


统计 信息 就 会 被 认为 过 | 昌 ， 将 导致 执行 计划 跑 偏 。 分 区 键 经 常 被 
区 表 创建 的 时 候 必须 使 


ENABLE ROW MOVEMENT。 


将 增加 其 后 分 裂 的 难度 。 做 列表 分 区 的 时 候 ， 需 要 注意 分 区 键 值 的 大 小 写 区 分 问题 。 


同时 要 考虑 到 CPU 的 并 发 处 理 能 力 。 


有 时， 如 年 度 中 的 月 份 ， 就 可 以 


这 种 类 型 的 分 区 。 数 据 在 整个 范 


围 中 能 被 均等 地 划分 时 性 能 最 好 。 


SQL> CREATE TABLE ALEX TPAR 
( 


ID 
CDATE 


NUMBER, 
VARCHAR2 (8) 


2 
E 
4 
5 
6 
7 
8 
9 
10 
11 
12 


PARTITION BY RANGE (CDATE) ( 

PARTITION par alex tpar 2013 ql VALUES LESS THAN 
PARTITION par alex tpar 2013 q2 VALUES LESS THAN 
PARTITION par alex tpar 2013 q3 VALUES LESS THAN 
PARTITION par alex tpar 2013 q4 VALUES LESS THAN 
PARTITION par alex tpar 2014 
) ENABLE RON MOVEMENT; — 


0 
(1 
(0 
(1 


VALUES LESS THAN 


20130401" 
20130701" 


) ， 
) ， 
201310017")， 
) ， 


20140101" 


(maxvalue) 


合 希 分 区 (Hash Partition) 提供 了 一 种 在 指定 数量 的 分 区 中 均等 地 划分 数据 的 方法 。 如 果 数 据 不 那么 容易 进行 范围 分 区 ， 但 为 了 性 能 和 管理 的 原因 又 想 分 区 时 ， 就 使 用 哈 希 分 区 方法 。 创 建 和 使 用 哈 


希 分 区 提供 了 一 种 很 灵活 的 放置 数据 的 方法 ， 进 而 来 影响 可 用 性 和 性 能 。 哈 希 分 区 的 每 个 分 区 的 数量 平均 ， 分 
提高 效率 。 哈 希 分 区 还 可 以 用 于 解决 热 块 的 问题 。 当 无 法 采用 范围 分 区 或 列表 分 区 时 ， 可 以 考虑 采用 哈 希 分 区 。 
丛 希 分 区 表 创 建 示例 如 下 : 
SQL> CREATE TABLE ALEX TPAR 
2 
0 NUMBER, 
NAME ~ VARCHAR2(8) 


3 
4 
号 
6 
7 
8 
9 


) 

PARTITION BY HASH (NAME) ( 
PARTITION par alex tpar 01, 
PARTITION par alex tpar 02, 


PARTITION par alex tpar 03, 


区 并 行 时 效率 高 ， 根 据 HASH 值 插入 数据 ， 可 以 将 数据 插入 到 不 同 的 块 ， 在 并 行 度 高 时 有 利于 


1 
1 


0 
1 


); 


PARTITION par alex tpar 04 


列表 分 区 (List Partition) 通常 用 于 应 用 中 可 以 通过 某 一 个 字段 来 平均 分 布 工作 负载 。 当 需要 明确 控制 如 何 将 数据 行 映射 到 分 区 时 ， 就 使 用 列表 分 区 方法 。 列 表 分 区 可 以 非常 自然 地 将 无 序 的 和 不 相关 
的 数据 集 进行 分 组 ， 并 组 织 到 一 起 。 与 范围 分 区 和 哈 希 分 区 有 所 不 同 ， 列 表 分 区 不 支持 多 列 分 区 ， 分 区 键 就 只 能 由 表 的 一 个 单独 的 列 组 成 。 
列表 分 区 表 创 建 示 例如 下 : 
SQL> CREATE TABLE ALEX TPAR 
ID NUMBER, 
4 CITY VARCHAR2 (8) 
5 
6 i BY LIST (CITY) ( 
2 PARTITION par alex tpar 01 VALUES ('SH','HZ"'), 
8 PARTITION par alex tpar 02 VALUES ('S2','G2'), 
9 PARTITION par alex tpar 03 VALUES ('BJ','TJ'), 
10 PARTITION par alex tpar 04 VALUES ('WH','CS') 
WE ) ENABLE ROW MOVEMENT; 
复合 分 区 的 选择 ， 从 性 能 、 数 据 管理 (数据 归档 ) 、 资 源 分 布 (应 用 的 分 区 ) 、 数 据 分 布 等 多 个 方面 进行 选择 。 如 果 侧 重 于 今后 对 按时 间 进 行 数 据 归 档 ， 则 可 以 采取 范围 列表 (Range-List) 分 区 方 
式 ; 如 果 侧 重 于 资源 分 布 ， 则 可 以 采用 列表 范围 (List-Range) 分 区 方式 。 如 果 两 方面 都 不 太 侧重 ， 则 可 以 再 关注 下 表 的 数据 分 布 ， 根 据 数据 的 分 布 情况 来 决定 采用 何 种 复合 分 区 方式 。 
范围 哈 希 分 区 表 创建 示例 如 下 : 


SQL> CREATE TABLE ALEX TPAR 
( 


2 
3 ID NUMBER, 
4 CDATE VARCHAR2 (8), 
4 NAME ~ VARCHAR2 (8)， 
5 ) 
6 PARTITION BY RANGE (CDATE) SUBPARTITION BY HASH(NAME) ( 
7 PARTITION par alex tpar 2013 ql VALUES LESS THAN ('20130401') ( 
8 SUBPARTITION sp alex tpar 2013qg1 01, 
9 SUBPARTITION sp alex tpar 2013q1 02, 
10 SUBPARTITION sp alex tpar 2013q1 03, 
SUBPARTITION sp alex tpar 2013q1 04), 
12 PARTITION par alex tpar 2013 q2 VALUES LESS THAN ('20130701'), 
13 SUBPARTITION sp alex tpar 2013q2 01, 
14 SUBPARTITION sp alex tpar 2013q2 02, 
15 SUBPARTITION sp alex tpar 201392 03， 
16 SUBPARTITION sp alex tpar 2013q2 04), 
a PARTITION par alex tpar 2014 VALUES LESS THAN (maxvalue) 
18 SUBPARTITION sp alex tpar max 01, 
19 SUBPARTITION sp alex tpar max 02, 
20 SUBPARTITION sp alex tpar max 03, 
21 SUBPARTITION sp alex tpar max 04), 
22  ) ENABLE RON MOVEMENT; 


Oracle 11g 中 , 分 
表 - 哈 希 (List-Hash) 的 组 合 分 区 策略 。 同 时 ， 也 新 增 了 几 种 针对 应 


区 策略 更 加 灵活 了 。 首 先 ，119 支 持 更 多 方式 的 组 合 分 | 


1. 间 隔 分 区 (Interval Partition ) 


当 我 们 按时 间 做 范围 
INTERVAL 分 


间隔 分 


分 


区 表 创建 示例 如 下 : 


区 时 ， 每 个 月 的 数据 存放 到 一 个 分 
区 时 ， 就 不 能 再 指定 LESS THAN (MAXVALUE) 了 ， 否 则 INTERVAL 分 


区 ， 除 10g 支 持 的 两 种 之 外 ， 还 支持 范围 


-范围 


(Range-Range) 、 列 表 - 范围 


场景 的 分 区 类 型 : 间隔 分 区 、 


系统 分 区 、 虚 拟 


列 分 区 、 关 联 分 区 。 


区 中 。 随 着 数据 的 增长 ， 需 要 人 工 定期 添加 新 的 分 


(List-Range) 、 列 表 - 列表 (List-List) 、 列 


多 


区 就 没有 意义 了 。 


间隔 分 


区 就 无 须 这 种 人 工 干 珊 了 ，Oracle 会 为 新 的 数据 


动 增加 分 区 。 在 指定 


10 


加 oamwm 必 wb 


SQL> CREATE TABLE ALEX TPAR 
( 


ID 
CDATE 


NUMBER, 
DATE 


) 
PARTITION BY RANGE 


(CDATE) 
INTERVAL (NUMTOYMINTERVAL (1, 


‘month')) ( 


PARTITION par alex tpar 2013 ql VALUES 
LESS THAN (TO DATE('20130401', "YYYymmdq' ) ) 
) ENABLE ROW MOVEMENT; 


2. 系 统 分 区 (System Partition) 


在 系统 分 区 中 是 不 需要 指定 任何 分 区 键 的 ， 数 据 会 进入 哪个 分 
特殊 性 ， 其 不 支持 分 区 分 裂 (Partition Split) 操作 和 CTAS 操 作 。 
系统 分 区 表 创 建 示例 如 下 : 


区 完全 由 SQL 本 身 来 决定 的 ， 即 在 INSERT 语 句 中 可 以 指定 插入 哪个 分 


区 了 。 在 插入 数 


届时 ， 如 果 没有 指定 分 


区 可 能 就 会 报错 。 由 于 系统 的 


oawm 必 ww 


SQL> CREATE TABLE ALEX TPAR 
( 


ID 
NAME 


NUMBER, 
VARCHAR2 (8) 


) 
PARTITION BY SYSTEM ( 


PARTITION par alex tpar 01, 


); 


PARTITION par alex tpar 02 


3. 虚 拟 列 分 区 (Virtual Column-Based Partition) 


这 种 列 中 的 数 


虚拟 列 分 


区 表 创建 示例 如 下 : 


届 并 不 实际 存储 于 磁盘 上 ， 而 是 通过 一 次 函数 的 实时 计算 才 得 到 的 


。 虚 拟 列 虽 然 没有 实际 的 存储 空间 ， 但 是 却 可 以 跟 其 他 普通 列 一 样 ， 创 建 索引 ， 作 为 分 


区 键 ， 甚 至 可 以 收集 统计 信息 。 


SQL> CREATE TABLE ALEX TPAR 
( 


ji 


3 
4 
号 
6 
7 
8 
9 
0 


ID NUMBER, 
BUY NUMBER, 
SELL NUMBER, 
GAIN NUMBER AS 
) 
PARTITION BY RANGE (GAIN) 


(SELL-BUY) 


( 


PARTITION par alex tpar 01 VALUES LESS THAN (10000), 
PARTITION par alex tpar 02 VALUES LESS THAN (20000), 


11 PARTITION par _ alex tpar max VALUES LESS THAN (maxvalue) 
12 ); 


4. 关 联 分 区 (Reference Partition) 


在 11g 之 前 的 版 本 中 ， 一 个 主 表 和 多 个 子 表 均 要 做 分 区 ， 我 们 就 需要 将 这 个 主 表 的 分 区 键 字段 匈 余 到 所 有 子 表 当中 去 ， 才 能 实现 相同 的 分 区 策略 。Oracle 11g 中 ， 可 以 通过 关联 分 区 解决 这 个 问题 了 。 
但 是 ， 关 联 分 区 不 能 指定 引用 分 区 的 上 下 限 ， 一 旦 父 表 的 分 区 发 生变 化 ， 子 表 分 区 也 会 自动 适应 ， 而 单独 修改 子 表 分 区 也 是 不 允许 的 。 


关联 分 区 表 创 建 示例 如 下 : 


SQL> CREATE TABLE ALEX TPAR PARENT 

( 
PID NUMBER PRIMARY KEY, 
CDATE VARCHAR2 (8) 


) 

PARTITION BY RANGE (CDATE) ( 

PARTITION par alex tpar 2013 q4 VALUES LESS THAN ('20140101°"'), 

PARTITION par alex tpar 2014 VALUES LESS THAN (maxvalue) 

) ENABLE ROW MOVEMENT; 

CREATE TABLE ALEX TPAR CHILD 

( 
CID NUMBER, 
PID NUMBER PRIMARY KEY, 
CONSTRAINT FK ALEX TPAR PID FOREIGN KEY (PID) 
REFERENCES ALEX TPAR PARENT (PID) 


SQ 


oanwNG oo Ian oN 


PARTITION BY REFERENCE (FK ALEX TPAR PID) 
ENABLE ROW MOVEMENT; 


3.6 ”适当 的 见 余 


适当 地 进行 数据 匈 余 ， 其 目的 就 是 为 了 “以 空间 换取 时 间 ”。 不 论 是 磁盘 存储 空间 还 是 内 存 空间 ， 都 可 以 适当 的 宛 余 ， 以 提升 处 理性 能 ,特别 是 针对 高 并 发 处 理 方面 ， 这 将 是 一 条 另辟蹊径 的 好 办 法 。 
前 面 我 们 都 在 说 如 何 精打细算 ， 如 何 节省 开销 ， 本 节 我 们 将 要 展开 讨论 一 下 如 何 来 “铺张 浪费 ”。 当 然 不 论 是 节省 还 是 “浪费 ”， 目 的 都 是 一 致 的 ， 保 证 高 并 发 的 处 理性 能 ， 只 是 思考 问题 的 角度 不 一 
样 ， 可 谓 “ 运 用 之 妙 ， 存 平一 心 ”。 


3.6.1 ” 反 范 式 建 模 


在 范式 化 的 数据 库 中 ， 每 个 事实 数据 会 出 现 有 且 仅 有 一 次 ， 反 之 ， 在 反 范 式 化 的 数据 库 中 ， 信 息 是 元 余 的 ， 可 能 会 存储 多 份 。 


来 通过 一 个 实例 分 析 一 下 吧 。 现 在 需要 存储 一 些 学 生 的 信息 ， 包 括 : 学 生 名 字 (Student) 、 班 级 名 字 (Class) 以 及 对 应 班级 班主 任 的 名 字 (Teacher) 。 按 照 范式 建 模 的 规则 ， 会 创建 如 下 两 种 表 : 
学 生 表 (Student 表 ) 和 班主 任 表 (Teacher 表 ) ， 因 为 班主 任 与 班级 的 对 应 关系 会 更 加 稳定 ， 而 且 基 本 上 是 一 对 一 的 关系 ， 将 Teacher 表 设 为 主 表 ，Student 表 为 子 表 ， 以 Class 字 段 相 关联 。 


Student Class Class Teacher 


Alex Classl Classl Smith 


Tom Class2 Class2 Brown 


这 样 的 范式 建 模 有 什么 优势 呢 ? 具体 如 下 : 

“ 范式 化 能 获得 比较 好 的 写 性 能 ， 因 为 没有 过 多 重复 的 数据 ， 通 常 来 说 更 新 和 新 建 操作 ， 其 可 通过 操作 更 少量 的 数据 完成 ; 

“ 范式 化 的 表 通常 也 会 比较 小 ， 便 于 缓存 ; 

“ 因为 没有 过 多 重复 性 的 数据 ， 只 需要 更 少 去 重 和 分 组 操作 ， 例 如 : DISTINT、UNION、GROUP BY 等 。 

但 是 ， 随 着 业务 量 扩展 和 数据 量 的 增加 ， 高 并 发 问题 应 运 而 生 ， 此 时 用 户 更 关心 的 应 该 是 响应 速度 ， 空 间 节省 可 能 不 会 太 在 意 了 。 范 式 化 就 呈现 出 它 的 劣势 了 : 
“ 表 数 量 过 多 ， 关 联 性 太 强 ， 强 耦合 性 不 够 灵活 ; 

“ 一 个 简单 的 业务 可 能 就 需要 联 立 很 多 表 ， 性 能 不 佳 ; 

“ 一些 核心 表面 临 高 并 发 的 时 候 ， 常 常 出 现 热 点 争 用 ， 拖 累 整 库 性 能 。 


完全 范式 化 建 模 的 数据 库 在 处 理 高 并 发 问题 的 时 候 ， 往 往 是 力不从心 的 ， 会 出 现 忙 的 表 忙 死 ， 闲 的 表 闲 死 。 基 于 以 上 的 问题 ， 我 们 推出 一 个 反 范 式 建 模 的 概念 。 简 单 地 说 ， 就 是 无 视 范式 。 还 是 拿 学 生 


信息 的 存储 来 分 析 吧 ， 按 照 完 全 范式 ， 我 们 需要 两 张 表 ， 大 多 数 业 务 都 会 需要 关联 两 张 表 ， 关 联 问题 是 产生 问题 的 关键 ， 那 我 们 就 不 要 这 样 的 关联 ， 通 过 一 个 表 实 现存 储 。 


Student Teacher 


Classl 


Class2 


Classl 


这 样 的 反 范 式 建 模 就 有 效 地 避免 了 关联 表 带 来 的 性 能 损耗 ， 这 种 设计 思路 也 是 为 了 解决 很 多 需要 高 并 发 快速 响应 的 业务 需求 。 需 要 快速 响应 的 ， 必 然 是 需要 结构 简单 的 ， 通 过 一 张 反 范式 的 表 ， 实 现 单 
表单 业务 ， 即 一 个 表 只 服务 一 项 业务 ， 一 项 业务 尽 可 能 通过 一 个 表 完 成 。 


然而 ， 反 范式 也 是 有 其 劣势 的 ， 过 多 的 数据 宛 余 导致 数据 存储 空间 的 浪费 ， 这 还 算是 比较 小 的 问题 ， 比 较 大 的 问题 应 该 是 保证 数据 的 强 一 致 性 。 看 一 下 上 面 反 范式 的 表 ，Alex 和 John 都 是 Class1 的 学 
生 ， 班 主任 是 Smith ， 如 果 现 在 只 更 新 John 这 一 行 的 Teacher 为 Green， 那 么 数据 不 一 致 就 产生 了 ，Class1 有 了 两 位 班主 任 ， 即 使 我 们 保留 了 Teacher 信 息 表 ， 也 没 办 法 避免 这 样 的 不 一 致 性 。 


3 


申 一 下 反 范 式 的 应 用 到 数据 库 层级 ， 其 实 就 是 分 布 式 数 据 库 设 计 了 。 数 据 库 与 数据 库 之 间 的 数据 强 一 致 性 保证 也 是 一 个 很 大 的 挑战 。 


在 这 里 ， 我 们 引进 一 个 分 布 式 数据 库 设 计 的 CAP 理 论 。 所 谓 CAP 就 是 数据 库 设计 的 三 要 素 : 
:一致 性 〈Consistency) : 任何 一 个 读 操作 总 是 能 读 取 到 之 前 完成 的 写 操作 结果 ， 也 就 是 在 分 布 式 环境 中 ， 多 点 的 数据 是 一 致 的 ; 
“ 可 用 性 (Availability) : 每 一 个 操作 总 是 能 够 在 确定 的 时 间 内 返回 ， 也 就 是 系统 随时 都 是 可 用 的 ; 


“ 分 区 可 容忍 性 (Partition) : 在 出 现 分 区 不 一 致 的 情况 下 ， 系 统 也 能 正常 运行 。 


在 数据 库 设 计 中 ，CAP 三 要 素 其 实 是 一 个 三 元 悖 论 ， 如 图 3-14 所 示 ， 即 一 个 分 布 式 数据 库 是 不 能 同时 满足 一 致 性 、 可 用 性 和 分 区 可 


一 2 性 


遇 
| 


性 这 三 个 需求 的 ， 最 多 只 能 同时 满足 两 个 ， 牺 牲 掉 另 一 个 。 


DataBase 


分 区 可 容 怒 性 可 用 性 


图 3-14 ”CAP 三 元 悖 论 


通常 来 说， 数据 的 一 致 性 我 们 是 很 看 重 


不 论 是 反 范 式 的 单 库 设计 ， 还 是 分 布 式 的 多 库 设 计 ， 都 是 一 种 “以 空间 换 时 间 ” 的 忽视 范式 化 的 设计 模式 。 都 应 该 把 保证 数据 一 致 性 放 在 第 一 位 考虑 ， 可 以 弱化 ， 但 不 能 忽视 。 不 幸 的 是 ， 要 保证 数据 


的 ， 即 使 在 一 些 互联 网 的 应 


一 致 性 最 好 的 做 法 却 是 范式 化 设计 。 


面 对 两 难 的 情况 ， 我 们 应 该 选择 混合 学 式 化 的 设计 模式 : 


“ 拆 分 前 端 表 〈 直 接 面 对 业 务 应 用 ) 和 后 端 表 〈 基 础 核心 ) ， 且 区 分 对 待 ; 


中 ， 谁 敢 说 不 需要 保证 数据 的 一 致 性 呢 ? 


“ 对 于 后 端 核心 的 东西 ， 使 用 范式 化 设计 ， 保 证 数据 强 一 致 性 ， 这 部 分 业务 数据 一 般 不 会 直接 面 对 高 并 发 的 应 用 压力 ; 


“ 对 于 需要 直接 面 对 高 并 发 压力 的 前 端 表 ， 尽 可 能 采用 分 库 分 表 ， 进 行 分 区 设计 ， 可 以 适当 弱化 数据 一 致 性 ; 


让 


表 政 


损失 的 数据 一 致 性 必须 可 以 通过 后 端 追 溯 回来 。 


“纵横 篇 ”介绍 的 TimesTen 内 存 技 术 和 GoldenGate 数 据 库 群 实现 ， 都 是 以 这 个 思路 为 出 发 点 的 。 


3.6.2 ”物化 视图 


视图 吗 ? 我 们 不 是 在 说 表 的 设计 吗 ? 确实 如 此 ， 我 们 是 在 说 表 的 设计 ， 物 化 视图 不 是 普通 的 视 | 
集 ， 并 可 以 自动 或 手动 地 刷新 这 个 结果 集 。 


1. 物 化 视 


[网 


原理 


这 次 我 们 先 通过 一 个 实例 来 一 宕 物化 视 | 


步骤 1 


SQL> create table alex 七 361 
SQL> create table alex 七 362 


图 的 庐山 真面目 吧 。 


创建 两 个 结构 一 样 的 测试 表 alex_t361 和 alex_t362: 


(id number, cnt number, name varchar2 (100)) 
(id number, cnt number, name varchar2 (100)) 


SQL> alter table alex t361 add constraint pk alex t361 


2 primary key (id) using index; 
SQL> alter table alex t362 add constraint pk alex t362 
2 primary key (id) using index; 


， 而 是 一 种 实体 化 的 视 


， 可 以 将 其 看 成 是 一 种 虚拟 的 表 ， 它 存储 的 是 基于 创建 时 指定 查询 返回 的 结果 


步骤 2 分 别 向 两 张 表 插入 100 万 条 随机 记录 行 ， 并 收集 两 个 表 相关 的 统计 信息 : 


SQL> declare 
2 begin 
for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 1000000 loop 


3 

4 insert into alex t361 

5 values 

6 (i, trunc(dbms_ random.value (1, 1000)), 
dbms random.string('Xx', 10)); 

8 insert into alex t362 

9 values 
10 (i, trunc(dbms_random.value (1, 1000)), 
14 dbms random.string('Xx', 10)); 

ig end loop; 
13 commit; 
14 end; 

起 光 


SQL> exec dbms stats 
SQL> exec dbms stats 
SQL> exec dbms stats 
SQL> exec dbms_stats 


.gather table stats 
.gather index stats 
.gather table stats 
.gather index stats 


'alex', 'alex 七 3617) 
'alex', 'pk alex t361') 
'alex', 'alex t362') 
'alex', 'pk alex t362') 


步骤 3 ”将 两 个 表 做 一 次 较为 复杂 的 联 立 查询 ,可 以 看 到 不 论 是 物理 读 和 钦 辑 读 ， 还 是 执行 返回 时 间 都 是 不 大 理想 的 ， 执 行 计划 中 的 全 表 扫 描 导 致 COST 开 销 也 很 大 : 


SQL> select sum(a.id) 
2 from alex t361 a, alex t362 b 


3 where a.name like 


4 and a.id=b.id 
5 group by a.cnt; 
Elapsed: 00: 00: 05.37 


'B%' and b.name like 'C%" 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 996 | 34860 | 1593 (4) | 
| 1 | HASH GROUP BY | | 996 | 34860 | 1593 (4) | 
| 二 亚当 HASH JOIN | | 23786 | 812K| 1591 (4) | 
| 二 | TABLE ACCESS FULL| ALEX T362 | 23783 | 371K| 795 (4) | 
|* 4 1 TABLE ACCESS FULL| ALEX T361 | 23858 | 442K| 了 795 (4) 1 
Statistics 


0 db block gets 


6938 consistent gets 
6926 physical reads 
523 rows processed 


步骤 4 ”创建 一 个 物化 视图 ， 开 启 查询 


看 写 ， 来 改善 一 下 性 能 : 


SQL> create materialized view log on alex t361; 
SQL> create materialized view log on alex t362; 
SQL> create materialized view mv alex 七 36 
refresh force on demand 

enable query rewrite 

as 

select sum(a.id) 

from alex t361 a, alex t362 b 

where a.name like 'B%' and b.name like 'C%' 
and a.id=b.id 

group by a.cnt; 


oANAOD 


步骤 5 重新 执行 一 下 步骤 3 的 复杂 查询 ， 各 方面 的 性 能 都 得 到 了 美妙 的 优化 : 


SQL> select sum(a.id) 
2 from alex t361 a, alex t362 b 
3 where a.name like 'B%' and b.name like 'C%' 
4 and a.id=b.id 
5 group by a.cnt; 
Elapsed: 00: 00: 02.11 


| Id | Operation | Name | Rows | Bytes | Cost (gsCPU) | 


| 0 | SELECT STATEMENT | | 523 | 799 | 3 (0) | 
| 1 | MAT VIEW REWRITE ACCESS FULL| MV ALEX T36 | 523 | $799 | 3 (0) | 
Statistics 


0 db block gets 
38 consistent gets 
0 physical reads 
523 rows processed 


可 以 看 到 通过 创建 物化 视图 ， 性 能 得 到 了 很 大 程度 的 提升 。 其 运行 机 制 如 图 3-15 所 示 ， 物 化 视图 通过 对 应 表 的 物化 视图 日 志 刷 新 数据 ， 并 将 结果 集 存储 到 独立 的 段 中 ， 客 户 端 查询 时 ， 如 果 有 物化 视 | 
的 存在 ， 其 实 就 是 使 用 简单 的 单 表 (物化 视图 ) 扫描 直接 返回 数据 蔡 代 复杂 得 多 表 联 立 操作 。 


网 


Client 


刷新 


图 3-15 ”物化 视图 机 制 


2. 物 化 视图 维护 


之 所 以 将 物化 视图 作为 一 种 匈 余 技术 来 介绍 ， 是 因为 它 是 需要 额外 的 存储 空间 的 ， 这 就 面临 着 这 部 分 空间 的 维护 ， 以 及 维护 带 来 的 成 本 开销 。 问 题 主要 集中 在 两 个 方面 : 刷新 模式 和 日 志 管 理 。 


物化 视图 可 以 选择 三 种 不 同 的 刷新 方式 : 


“ 全 量 刷新 (Complete Refresh) : 会 删除 视图 中 的 所 有 记录 (如 果 是 单 表 刷 新 ， 可 能 会 采用 Truncate 的 方式 ) ， 然 后 根据 物化 视图 中 查询 语句 的 定义 重新 生成 物化 视 医 


“ 快速 刷新 (Fast Refresh) : 采用 增 量 刷新 的 机 制 ， 只 将 自 上 次 刷新 以 后 对 基 表 进行 的 所 有 操作 刷新 到 物化 视图 中 ; 


“ 强制 刷新 (Force Refresh) : Oracle 自 动 判断 是 否 满足 快速 刷新 条 件 ， 如 果 满 足 则 进行 快速 刷新 ， 否 则 进行 全 量 刷 新 。 


从 保证 性 能 的 角度 出 发 ， 非 异常 必要 情况 ， 全 量 刷新 不 要 使 用 ， 因 为 其 会 将 表 清 空 后 重新 复制 数据 ， 将 占用 大 量 的 资源 。 而 强制 刷新 方式 Oracle 自 动 判断 是 否 满足 快速 刷新 条 件 ， 如 果 满足 则 进行 快速 
刷新 ， 否 则 进行 全 量 刷新 ， 使 用 强制 刷新 方式 带 有 不 确定 性 ， 因 此 不 要 使 用 强制 刷新 方式 。 


为 了 保证 性 能 我 们 已 经 把 全 量 刷新 和 强制 刷新 堵 上 了 ， 只 进行 快速 刷新 ， 在 快速 刷新 的 方式 下 ， 也 有 一 些 相关 的 限制 需要 注意 ， 其 只 能 用 基于 ROWID 的 物化 视图 。 


关于 刷新 ， 另 一 个 值得 注意 的 是 On Commit 刷 新 模式 和 On Demand 模 式 的 选择 : 
On Commit 模 式 : 视图 数据 基于 基 表 提交 时 更 新 ; 


“On Demand 模 式 : 根据 自己 需要 刷新 数据 ， 也 可 以 根据 刷新 包 手 动 刷新 。 


On Commit 的 刷新 模式 数据 库 会 将 物化 视 | 
并 且 尽 量 使 用 手动 刷新 。 


[ 


的 刷新 操作 作为 Commit 事 务 处 理 的 一 部 分 来 执行 ， 从 而 增加 了 Commit 完 成 的 时 间 ， 这 是 应 该 尽量 避免 的 ， 所 以 我 们 这 里 需要 使 用 On Demand 的 模式 ， 


再 来 说 一 说 物化 视图 的 日 志 管理 吧 。 物 化 视图 日 志 会 记录 下 基 表 所 有 的 增删 改 的 操作 ， 而 物化 视图 执行 快速 刷新 操作 后 ， 会 从 日 志 中 将 该 物化 视图 刷新 过 且 其 他 物化 视图 所 不 需要 刷新 的 记录 删除 掉 。 
如 果 其 中 一 个 物化 视图 一 直 不 刷新 ， 那 么 物化 视图 日 志 就 会 变 得 越 来 越 大 。 物 化 视图 日 志 经 常会 由 于 物化 视图 长 时 间 没有 刷新 ， 或 者 基 表 的 一 次 批量 数据 更 改 而 变 得 很 大 ， 这 会 影响 物化 视图 的 刷新 性 能 ， 
因此 对 于 这 种 情况 需要 对 物化 视图 日 志 进行 处 理 ， 降 低 物化 视图 日 志 表 的 高 水 位 线 。 


对 于 日 志 表 的 清理 ， 我 们 不 能 简单 使 用 Truncate Table 的 操作 ， 因 为 无 法 保证 在 操作 之 前 ,物化 视图 的 基 表 不 被 修改 。 一 旦 被 修改 ， 此 时 日 志 表 被 Truncate 掉 了 ， 就 会 导致 物化 视图 和 基 表 的 数据 不 一 
致 ， 这 是 绝 不 可 取 的 。 即 使 可 以 在 操作 期 间 对 表 加 锁 ， 也 是 无 法 保证 日 志 表 的 数据 一 致 性 或 者 Truncate 不 会 失败 。 比 较 好 的 方法 还 是 通过 MOVE TABLE 的 方式 来 实现 日 志 表 清理 。 


加 


为 了 保证 性 能 ， 查 询 重 写 (Query Rewrite) 也 是 需要 注意 的 ， 其 包括 ENABLE QUERY REWRITE 和 DISABLE QUERY REWRITE 两 种 ， 分 别 表示 创建 的 物化 视图 是 否 支持 查询 重 写 。 查 询 重 写 是 指 当 对 
物化 视图 的 基 表 进行 查询 时 ，Oracle 会 自动 判断 能 否 通过 查询 物化 视图 来 得 到 结果 ， 如 果 可 以 ， 则 避免 了 聚集 或 联 立 操作 ， 而 直接 从 已 经 计算 好 的 物化 视图 中 读 取 数据 。 默 认为 DISABLE QUERY 
REWRITE。 


这 里 也 多 说 一 句 ， 可 能 有 人 会 说 物化 视图 更 适用 于 OLAP 系 统 的 应 用 ， 制 作 一 些 报表 等 。 不 错 ， 这 是 一 种 不 错 的 物化 视图 应 用 场景 ， 但 是 换 一 个 角度 思考 的 话 ， 在 OLTP 系 统 中 ， 能 完全 避免 MI1S 报 表 相 
关 的 一 些 东西 吗 ” 将 其 压力 分 散 到 物化 视图 上 去 了 ， 前 端 容易 出 现 高 并 发 问题 的 概率 也 会 小 很 多 了 。 


说 到 这 里 ， 是 不 是 很 容易 从 物化 视图 联想 到 索引 呢 ? 从 某 种 意义 上 来 看 ， 两 者 确实 有 不 少 相 似 之 处 。 比 如 : 


“ 使 用 索引 和 物化 视图 的 目的 都 是 为 了 提高 查询 


全能 ; 


“索引 和 物化 视图 对 应 用 都 是 透明 的 ， 增 加 和 删除 索引 或 物化 视图 不 会 影响 应 用 程序 中 SQL 语句 执行 的 正确 性 和 有 效 性 ; 


:索引 和 物化 视图 都 是 实体 对 象 ， 需 要 占用 存储 空间 ; 


“ 当 基 表 发 生变 化 时 ， 物 化 视图 需要 刷新 ， 索 引 也 需要 刷新 〈 维 护 ) 。 


然而 ， 我 们 应 该 更 关心 的 是 不 同 之 处 吧 ， 确 定 什么 时 候 建 索 引 ， 什 么 时 候 建物 化 视图 ? 


:一般 来 说 ， 第 一 考虑 就 是 创建 索引 ， 但 是 索引 使 用 有 一 定 的 局 限 性 ， 必 须 遵守 一 定 选择 度 和 合适 的 聚 仁 因子 要 求 ， 对 于 返回 结果 集 数 据 量 占 比 较 大 的 情况 ， 就 无 法 使 用 索引 ; 


“ 物化 视图 可 以 视 为 索引 不 足 场景 的 补充 ， 对 于 需要 全 表 扫描 的 情况 ， 物 化 视图 是 个 不 错 的 优化 选择 。 


3.6.3 ”结果 集 缓存 


缓存 技术 在 数据 库 性 能 优化 的 应 用 中 ， 似 乎 是 无 处 不 在 的 。 前 面 说 到 的 物化 视图 也 可 以 理解 成 一 种 缓存 的 技术 ， 将 结果 集 缓存 在 一 个 实体 化 的 虚拟 表 中 。 但 是 ， 物 化 视图 提供 的 是 查询 重 写 的 功能 ， 一 
定 程 度 上 只 是 简化 了 SQL 的 复杂 度 ， 即 使 是 完全 满足 查询 条 件 ， 物 化 视图 的 扫描 也 是 不 可 避免 的 ， 也 就 是 说 物理 读 是 不 可 以 避免 的 。 在 Oracle 11g 中 ， 引 进 了 一 个 新 的 特性 用 于 缓存 结果 集 到 高 速 缓存 中 ， 
就 是 结果 集 缓存 (Result Cache) 技术 。 


[ 


数据 库 高 速 缓存 (Buffer Cache) 在 之 前 的 应 用 中 ， 都 是 只 能 缓存 访问 过 的 数据 块 ， 一 定 程度 上 解决 了 物理 读 的 问题 ， 查 询 仍然 需要 大 量 的 逻辑 读 ， 甚 至 会 出 现 内 存 热点 区 域 的 高 并 发 争 用 ， 影 响 整个 
高 速 缓存 的 正常 运作 。 如 果 将 一 些 频 繁 使 用 、 但 是 变化 不 大 的 结果 集 像 数据 块 一 样 缓存 起 来 ， 查 询 时 直接 即 可 返回 ， 不 需要 额外 的 逻辑 读 和 额外 的 复杂 计算 ， 数 据 块 的 高 并 发 热点 争 用 也 会 相对 减少 。 这 就 
是 结果 集 缓存 的 实现 原理 。 


基于 结果 集 缓存 的 应 用 ，Oracle 新 增 了 两 个 HINT 关 键 字 一 一 result cache 和 no_result cache， 可 以 明确 地 指出 SQL 语句 是 否 进行 结果 集 缓存 。Oracle 还 增加 了 几 个 初始 化 参数 来 管理 结果 集 缓 存 功 


mp 
GCC 


* RESULT_CACHE_MAX_SIZE: 指明 SGA 中 result_cache 功 能 可 以 使 用 的 最 大 的 内 存 容量 ， 参 数 设置 为 0， 则 关闭 结果 集 缓存 功能 ; 


“ RESULT_CACHE_MODE: 该 参数 设置 结果 集 缓存 使 用 的 模式 ， 其 三 个 值 为 MANUAL (只 有 在 指定 HINT 关 键 字 才 会 使 用 ) 、AUTO (自动 判读 ) 、FORCE (无 视 HINT 关 键 字 而 强制 使 用 ) 。 


对 于 上 一 节 物 化 视图 的 例子 ， 如 果 是 用 结果 集 缓存 技术 来 优化 ， 结 果 将 会 如 何 呢 ? 我 们 知道 结果 集 缓存 是 在 高 速 缓存 中 开辟 一 块 特定 区 域 来 缓存 特定 查询 的 结果 集 的 ， 因 此 我 们 需要 先 将 结果 集 缓存 起 
来 ， 也 就 是 说 某 个 查询 第 一 次 执行 的 时 候 ， 完 成 结果 集 缓存 ， 这 个 过 程 是 结果 集 缓存 没有 办 法 起 作用 的 ， 当 第 二 次 执行 同样 的 查询 的 时 候 ， 结 果 集 缓存 作用 生效 。 以 上 查询 第 二 次 执行 的 结果 如 下 : 


SQL> select /*tresult cache*/ sum(a.id) 
2 from alex t361 a, alex t362 b 
3 where a.name like 'B%' and b.name like 'C%' 
4 and a.id=b.id 
5 group by a.cnt; 
Elapsed: 00: 00: 02.06 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT IL! ] 996 | 34860 | 1593 (4) 1 
| 1 | RESULT CACHE | 8nquxwvmp058vfzvupjrwauzxl | | | 
| 21] HASH GROUP BY | ] 996 | 34860 | 1593 (4) | 
i | HASH JOIN | | 23786 | 812K| 1591 (4) | 
| TABLE ACCESS FULL| ALEX T362 | 23783 | 371K]| 795 (4) 1 
上 二 要 证 TABLE ACCESS FULL| ALEX T361 | 23858 | 442K| 795 (4) 1 


1 - colum-count=1; 

dependencies= (ALEX.ALEX T36]1, ALEX.ALEX T362); 
parameters= (nls); 
name="select /*+tresult cache*/ 

from alex t361 a, alex t362 b 

where a.name like 'B%' and b.name like 'C%' 
and a.id=b.id 

group" 

Statistics 

0 db block gets 

0 consistent gets 

0 physical reads 

3 rows processed 


我 们 可 以 看 到 ， 执 行 计划 路 径 发 生 了 变化 ， 提 示 走 的 是 结果 集 缓 存 。 虽 然 整体 执行 计划 的 COST 开 销 没 有 变化 ， 但 是 统计 信息 中 赫然 发 现 此 次 查询 没有 物理 读 和 逮 辑 读 ， 它 是 直接 从 高 速 缓存 返回 结果 集 
的 ， 那 执行 时 间 当 然 也 会 比 物化 视图 更 有 优势 。 


如 图 3-16 所 示 ， 结 果 集 缓存 的 作用 机 制 是 在 SGA 内 存 区 域内 ， 几 乎 与 任何 物理 结构 没有 关系 ， 它 就 像 前 置 在 SGA 中 的 一 个 “内 存 数据 表 ”。 不 论 是 普通 的 查询 还 是 物化 视图 查询 ， 都 是 需要 先 在 高 速 缓 
存 中 缓存 数据 块 ， 再 进行 数据 块 的 计算 和 组 合 。 


再 注意 看 一 下 “Result Cache Information” 提 供 的 信息 ， 如 果 不 使 用 结果 集 缓 存 ， 这 部 分 内 容 是 不 会 有 的 。 结 果 集 缓存 在 缓存 SQL 语句 的 返回 结果 集 的 同时 ， 对 依赖 对 象 表 alex_t361 和 表 alex_t362 
也 进行 了 必要 的 缓存 。 


以 下 SQL 语句 可 以 帮助 大 家 查询 哪些 对 象 和 SQL 语句 是 被 作为 结果 集 缓存 起 来 了 的 。 


SQL> select cache id, type, name, row count 


2 from v$result cache objects 

3 where status = 'Published'; 
CACHE_ID TYPR NAMP ROW_COUNT 
ALEX.ALEX T362 Dependency ALEX.ALEX T362 0 
ALEX.ALEX T361 Dependency ALEX.ALFEX T361 0 
8nquxwvmp058vfzvupjrwauzx1 Result select /*+result cache*/ sum(a.id) 558 


from alex t361 a, alex t362 b 


where a.name like 'B%' and b.name like "CS%" 
and a.id=b.id 
group by a.cnt 


刷新 


3-16 结果 集 缓存 机 制 


如 果 不 希望 走 结果 集 缓存 返回 结果 ， 可 以 使 用 no_result_cache 关 键 字 ， 此 时 查询 SQL 语句 将 从 高 速 缓存 中 通过 计算 数据 块 返回 结果 ， 自 然 就 多 了 一 些 逻 辑 读 的 开销 。 


SQL> select /*+no result cache*/ sum(a.id) 
2 from alex t361 a, alex t362 b 
3 where a.name like 'B%' and b.name like 'C%' 
4 and a.id=b.id 
5 group by a.cnt; 
Elapsed: 00: 00: 02.57 
Statistics 
2 db block gets 
6938 consistent gets 
0 physical reads 
523 rows processed 


结果 集 缓存 技术 虽然 能 有 效 地 提升 查询 性 能 ,但 是 不 可 以 广泛 使 用 : 一 方面 ， 会 导致 高 速 缓存 的 内 存 不 足 ， 反 而 拖累 了 高 速 缓存 的 正常 使 用 ; 另 一 方面 ， 如 果 对 结果 集 有 数据 变化 ， 反 而 会 成 为 性 能 
负担 。 


缓存 结果 集 的 内 存 使 用 情况 可 以 通过 查询 如 下 数据 字典 来 确定 ， 当 内 存 使 用 量 过 多 时 ， 需 要 用 系统 包 dbms_result_cache 及 时 清理 。 


SQL> select name, sum (bytes) 
2 from v$sgastat 
3 where name like 'Resultsg'" 
4 group by name; 
NAME, SUM (BYTES) 


Result Cache 143960 


3.6.4 直接 路 径 插入 


Oracle 数 据 库 提 供 了 两 种 类 型 的 INSERT 语 句 来 向 表 中 加 载 数据 ， 即 常规 路 径 插入 (Conventional-path Insert) 和 直接 路 径 插入 (Direct-path Insert) 。 


常规 路 径 的 插入 就 是 我 们 通常 说 的 插入 行为 ，Oracle 会 先 判断 在 高 水 位 线 (High Water Mark) 以 下 是 否 有 空闲 空间 ， 如 果 有 则 将 新 值 插入 到 该 空闲 空间 中 ， 如 果 没有 足够 的 空间 ， 则 推 高 高 水 位 线 将 
新 值 插入 。 


直接 路 径 插入 如 图 3-17 所 示 ， 则 是 直接 将 新 值 插入 到 高 水 位 线 以 上 的 区 域 ， 再 推 高 高 水 位 线 ， 省 去 了 判断 原 高 水 位 线 以 下 是 否 有 空闲 空间 的 动作 。SQL*Loader 和 exp/imp 也 都 有 直接 路 径 导数 的 方式 ， 


效率 较 常规 方式 高 很 多 。 
PCTFREE 


区 本 


图 3-17 直接 路 径 插入 


直接 路 径 插入 


High Water Mark 


销 规 路 径 插 入 


那么 直接 路 径 插入 的 方式 ， 其 优势 在 哪里 呢 ? 它 又 可 以 用 来 解决 什么 问题 呢 ? 先 来 看 一 下 对 比 常规 路 径 插入 的 优势 吧 : 


. 由 于 直接 写 的 缘故 ， 其 吉 开 了 高 速 缓存 ; 


: 省 去 了 高 水 位 线 下 空闲 空间 的 寻 址 操作 ， 插 入 效率 提高 ; 


“ 只 生成 最 少量 的 UNDO ， 仅 为 空间 管理 操作 做 了 UNDO ; 


' 只 生成 必要 量 的 REDO 上 日 志 ， 如 果 使 用 最 小 日 志 (NOLOGGING) 模式 ， 日 志 量 将 更 少 。 


直接 路 径 插入 能 解决 什么 问题 呢 ? 具体 如 下 : 


: 在 高 并 发 写 压力 较 大 的 时 候 ， 使 用 直接 路 径 插 入 实现 批量 操作 ， 可 以 获得 更 快 的 响应 ， 缓 解 并 发 压力 ; 


“ 在 高 并 发 读 压 力 较 大 的 时 候 ， 直 接 路 径 插 入 的 方式 缓解 压力 的 效果 将 更 好 ， 不 过 需要 保证 读 操作 基本 都 是 走 索引 的 ， 因 为 其 将 加 大 全 表 扫 描 的 开销 ; 


: 缓解 UNDO 和 REDO 的 争 用 压力 。 


直接 路 径 插入 的 方式 也 存在 其 作用 域 ， 存 在 一 些 相关 的 限制 : 


" 最 常见 的 带 有 VALUE 子 句 的 INSERT 语 句 不 支持 直接 路 径 插 入 ; 

最 常用 在 INSERT INTO…SELECT… 结 构 的 播 入 语句 中 ; 

“ 直接 路 径 插入 数据 的 事务 在 提交 之 前 ， 其 他 基于 该 表 的 DML 操 作 (DELETE、INSERT、MERGE、UPDATE) 及 索引 的 创建 或 重建 都 是 被 禁止 的 ; 
“ 高 水 位 以 下 的 空闲 数据 块 将 不 被 使 用 ， 可 能 会 因此 导致 表 无 限 扩张 ; 


“ 当 被 操作 的 表 上 存在 INSERT 触 发 器 、 外 键 、 表 类 型 是 IOT、 表 使 用 到 了 聚 答 技术 ， 以 及 表 中 包含 LOB 字 段 时 ， 直 接 路 径 加 载 技术 是 无 效 的 ， 此 时 将 会 自动 的 转变 为 常规 插入 。 


说 了 这 么 多 ， 我 们 一 起 来 看 一 下 直接 路 径 插入 的 实际 效果 吧 。 先 创建 一 个 测试 表 alex_t37 用 于 插入 数据 的 存储 。 先 在 该 表 中 随意 插入 并 删除 一 些 数据 ， 再 通过 以 下 三 种 方式 插入 数据 ， 为 了 使 效果 更 明 
显 ， 各 循环 执行 100 次 。 


SQL> create table alex t37 as select * from dba objects where 0=1; 


1) 常规 路 径 插入 操作 : 


SQL> insert into alex t37 select * from dba objects; 


2) 直接 路 径 插 入 操作 : 


SQL> insert /*+ append */ into alex t37 select * from dba objects; 


3) 最 小 日 志 的 直接 路 径 插 入 操作 : 


SQL> insert /*+ append */ into alex t37 nologging 
2 select * from dba objects; 


通过 以 下 语句 监控 会 话 级 别 的 统计 信息 数据 : 


SQL> select b.name，a.value 
有 from VS$mystat a, v$statname b 
3 where a.statistic# = b.statistic# 
4 and b.name in 
生 ('undo change Vector size', 
6 'redo size', 'session logical reads'); 


三 种 插入 方式 的 效率 如 图 3-18 所 示 ， 可 以 看 到 直接 路 径 插 入 的 整体 效率 要 比 常规 路 径 高 很 多 ， 从 几 个 维度 来 分 别 比较 一 下 : 


“ 响应 时 间 : 这 个 应 该 是 我 们 最 关心 的 ， 响 应 越 快 ， 影 响 就 越 小 ， 高 并 发 处 理 能 力 就 会 越 高 。 直 接 路 径 插 入 方式 下 ， 响 应 时 间 有 一 点 的 优势 ， 但 不 是 很 明显 ， 主 要 是 因为 测试 表 上 没有 任何 索引 ， 否 则 
的 话 ， 这 个 差距 将 会 加 大 。 


“ 逻辑 读 : 常规 路 径 插 入 的 方式 会 先 判断 高 水 位 线 下 的 空闲 空间， 会 有 额外 的 逻辑 读 。 


“ REDO 量 : 从 REDO 量 来 看 ， 如 果 直 接 路 径 插 入 不 使 用 NOLOGGING 模 式 的 话 ， 是 没有 太 大 的 优势 的 。 但 是 ， 我 们 现在 大 部 分 的 生产 数据 库 都 是 有 Standby 的 容 灾 数 据 库 的 ， 这 就 是 不 可 避免 地 需要 设 
置 数据 库 级 别 FORCE LOGGING， 那 么 NOLOGGING 模 式 就 不 会 生效 了 。 对 于 OLTP 系 统 来 说 ， 即 使 没有 容 灾 数据 库 ， 也 尽量 不 要 使 用 NOLOGGING 模 式 ， 会 影响 到 数据 库 的 恢复 还 原 。 


“ UNDO 量 : 直接 路 径 揪 入 的 优势 非常 明显 ， 其 UNDO 量 几乎 可 以 忽略 不 计 。 这 是 因为 被 修改 的 表 上 没有 索引 ， 即 使 有 索引 的 存在 ，UNDO 产 生 量 的 优势 也 是 很 显著 的 ， 因 为 其 仅 为 空间 管理 操作 做 了 
UNDO。 


口 NOLOGGING 直 接 路 径 插 入 ” 口 直接 路 径 插 入 ” 国 常 规 路 径 插 入 


] 0.58% 
UNDO 量 | 0.59% 


100.00% 


0.14% 


REDO 量 EE 1 00.89% 
100.00% 


| |117.01% 
逻辑 读 是 M17.05% 
100.00% 


| |33.55% 
响应 时 间 和 和 和 和 和 是 时 于 到 到 90.15% 
100.00% 


3-18 直接 路 径 插 入 效率 对 比 


值得 提 一 下 的 是 ， 直 接 路 径 插 入 是 不 支持 并 行 操作 的 ， 但 即使 如 此 ， 其 效率 也 会 比 常规 路 径 插入 的 并 行 操作 要 高 。 


对 于 并 发 度 较 高 的 表 ， 尽 量 避 免 频 繁 的 INSERT 等 事务 操作 ， 减 少 COM MIT， 一 定 程度 上 的 使 用 直接 路 径 插 入 数据 ， 特 别 是 批量 数据 的 插入 ， 是 可 以 预期 到 比较 不 错 的 效果 的 。 


3.7 碎片 分 析 与 整理 


上 一 章 中 ， 我 们 介绍 了 索引 碎片 的 概念 ， 当 索引 碎片 率 很 高 的 时 候 ， 需 要 重建 索引 降低 碎片 率 ， 提 高 索引 的 使 用 效率 。 同 样 ， 当 频繁 DML 操 作 (DELETE 操 作 ) ， 表 也 会 产生 碎片 。 对 于 表 来 说 ,碎片 
也 不 是 什么 好 东西 ， 碎 片 率 过 高 可 能 会 导致 : 


“ 表 的 使 用 效率 、 系 统 性 能 减弱 ; 


: 浪费 大 量 的 表 空 间 。 


然而 ， 表 的 结构 和 索引 不 一 样 ， 其 结构 更 简单 ， 是 不 一 定 需要 进行 重建 来 降低 碎片 率 的 ， 可 以 通过 简单 地 整理 即 可 完成 。 


下 面 我 们 将 介绍 表 的 碎片 是 如 何 产生 的 ， 如 何 发 现 表 的 碎片 情况 ， 以 及 通过 哪些 手段 可 以 修复 表 的 碎片 问题 。 


3.7.1 碎片 的 产生 


在 开始 讲解 表 的 碎片 之 前 ， 先 要 说 说 高 水 位 线 (High Water Mark) 这 个 概念 。 想 必 很 多 读者 已 经 很 清楚 了 ， 前 面 的 章节 也 有 过 一 些 介绍 。 在 Oracle 数 据 库 中 ， 所 有 的 段 (包括 表 ) 都 有 一 个 在 段 内 容 
纳 数 据 的 上 限 ， 我 们 把 这 个 上 限 称 为 该 段 的 高 水 位 线 。 高 水 位 线 指示 了 有 多 少 可 以 使 用 的 数据 块 分 配给 这 个 段 ， 包 括 : 填 满 的 数据 块 、 空 数据 块 、 未 填 满 的 数据 块 ， 通 常 其 增长 的 幅度 为 一 次 5 个 数据 块 。 当 
段 需要 更 多 数据 块 的 时 候 ， 高 水 位 线 会 上 升 ; 当 段 进行 空闲 块 回收 的 时 候 ， 高 水 位 线 会 下 降 。 


高 水 位 线 对 数据 库 操作 有 如 下 影响 : 


“ 全 表 扫 描 通常 要 读 出 直到 高 水 位 标记 的 所 有 属于 该 表 数 据 库 块 ， 即 使 该 表 中 没有 任何 数据 ; 


“ 直接 路 径 插入 数据 的 时 候 ， 使 用 的 是 高 水 位 线 以 上 的 数据 块 ， 此 时 高 水 位 线 会 自动 增 大 。 


那 什么 是 表 的 碎片 呢 ， 跟 高 水 位 线 有 什么 关系 呢 ? 表 的 碎片 就 是 表 的 高 水 位 线 以 下 、 没 有 充分 利 


的 数据 块 。 如 果 以 数据 块 为 最 小 单位 来 看 的 话 ， 碎 片 就 是 高 水 位 线 以 下 的 空闲 数据 块 。 但 是 ， 我 们 似 


应 该 将 粒度 统计 得 更 细 一 些 ， 对 于 没有 完全 填 满 的 数据 块 ， 也 要 细 粒 度 分 析 一 下 ， 比 如 : 一 个 数据 块 的 充盈 度 为 50%， 那 么 另外 50% 则 视 为 碎片 ， 也 就 是 说 高 水 位 线 以 下 ， 没 有 用 于 实际 存储 数据 的 空间 
都 可 视 为 碎片 。 


碎片 是 如 何 产生 的 呢 ? 理解 了 碎片 的 定义 ， 这 个 问题 应 该 不 难 回答 了 。 如 图 3-19 所 示 ， 假 设 每 行 记 录 对 应 一 个 数 


块 空间 是 不 会 被 回收 的 ， 它 将 作为 高 水 位 线 以 下 的 空闲 空间 被 识别 ， 那 么 这 部 分 空间 就 是 我 们 所 说 的 碎片 ， 也 就 是 说 这 次 DELETE 操 作 制 造 了 这 个 碎片 。 


那么 这 个 碎片 是 不 是 一 直 会 作为 碎片 存在 下 去 呢 ? 当然 不 是 ， 当 有 新 值 插 入 的 时 候 ， 这 部 分 空间 将 可 能 会 


回 到 前 面 的 那个 表 alex_t37 来 做 个 测试 ， 看 看 碎片 对 性 能 的 影响 吧 。 


PGIFREE 


High Water Mark 


行 01 


步骤 1 ”随意 删除 一 些 数据 ， 制 造 表 alex_t37 的 碎片 : 


3-19 碎片 的 产生 


居 块 ， 当 行 02 被 DELETE 掉 了 ， 那 么 行 


02 记 录 不 复 存 在 ， 但 是 原来 存储 行 02 记 录 的 数据 


于 存储 新 值 。 一 定 程度 上 来 说 ， 表 的 碎片 是 不 可 避免 的 ， 但 是 可 以 控制 的 。 


行 02 


SQL> delete from alex t37 where object name like 'B%S'; 
94900 rows deleted 加 

SQL> delete from alex t37 where object name like 'G%'; 
8090 rows deleted 加 | 

SQL> delete from alex t37 where object name like 'F%'; 
570 rows deleted 加 加 

SQL> delete from alex t37 where object name like 'P%'; 
9460 rows deleted 

SQL> delete from alex t37 where object name like 'L%'; 
6420 rows deleted 

SQL> delete from alex t37 where object name like 'W%'; 
16940 rows deleted 


步骤 2 ”再 按照 alex_t37 表 一 样 的 数据 和 结构 新 建 一 张 表 alex_t38， 作 为 对 比 参 照 : 


SQL> create table alex t38 as select * from alex 七 377 
Table created 


步骤 3 同样 的 查询 ， 同 样 的 全 表 扫描 ， 在 表 alex_t37 上 的 COST 开 销 更 大 ， 因 为 其 需要 扫描 更 多 的 数据 块 。 在 表 alex_t38 中 几乎 没有 碎片 ， 数 据 块 利 


率 高 ， 全 表 扫描 的 效率 也 就 高 了 。 


SQL> select count (*) from alex t37 where object name like 'T%'; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 工 | 25 | 2225 (1)1 
| 1 | SORT AGGREGATE 1 | 二 25 | | 
号 这 于 TABLE ACCESS FULL| ALEX T37 | 7033 | TIKI 2225 A 


0 db block gets 
9381 consistent gets 
9372 physical reads 
rows processed 
SQL> select count (*) from alex t38 where object name like 'T%'; 


| Bytes | Cost (%CPU)| 
0 | SELECT STATEMENT | | 工 | 25 | 1494 (1)1 
1 | SORT AGGREGATE 1 | 二 FP | | 
a TABLE ACCESS FULL| ALEX T38 | 7039 | 171K| 1494 *L 


0 db block gets 
6658 consistent gets 
6650 physical reads 

1 rows processed 


有 的 人 可 能 会 提 到 一 个 观点 : 


“ 表 的 碎片 没有 整理 的 必要 ， 因 为 我 都 是 通过 索引 来 检索 数 


居 的 ， 不 受 高 水 位 线 的 约束 ， 只 要 做 好 索引 碎片 的 整理 就 好 了 。 ”如 果真 的 能 做 到 这 一 点 当然 是 最 好 了 ， 那 很 


多 问题 都 能 解决 了 。 话 说 回来 ， 若 碎片 率 很 高 ， 则 数据 块 利 


3.7.2 DBMS SPACE 包 


Tom Kytel1] 大 师 | 
情况 。 如 果 数 据 块 利 


的 书 上 不 只 一 次 提 到 过 DBMS_SPACE 这 个 包 ， 及 基于 这 个 包 的 SHOW_SPACE 自 定义 过 程 ， 它 通过 分 析 表 的 方式 判断 组 成 表 的 数 折 
率 不 高 ， 则 说 明 表 的 碎片 率 很 高 ， 需 要 进行 碎片 整理 。 这 个 包 对 分 析 表 的 碎片 率 很 有 帮助 。 


我 们 使 


这 个 包 来 方便 快捷 地 确定 一 个 表 的 碎片 率 ， 分 析 一 个 表 的 碎片 率 比分 析 一 个 索引 的 碎片 效率 要 高 得 多 。 


先 结合 前 面 说 到 的 碎片 的 定义 ， 来 归纳 一 个 碎片 率 统计 的 方法 论 


四 


使 


DBMS_SPACE.SPACE_USAGE 分 析 目 标 表 ， 可 以 获取 高 水 位 线 以 下 数据 块 空闲 度 分 布 结构 


网 


届 块 的 利 


率 很 低 ， 如 果 在 索引 扫描 时 进行 范围 扫描 ， 那 么 对 应 的 数据 块 数量 也 会 比 没有 碎片 的 要 多 一 些 。 


网 


映 其 分 布 


率 情况 ， 并 构建 统计 的 直方 


， 其 按照 4 个 区 段 来 对 数据 块 的 充盈 度 进行 归纳 : 0~25%，25%~50%，50%~75%，75~100%。 如 表 


3-2 所 示 ， 可 以 按照 4 个 区 段 分 别 做 加 权 平 均 ， 比 如 : 25%~ 50% 这 个 区 段 的 数据 块 数量 为 pb， 那么 可 以 认为 b/2 数 量 的 数据 块 为 25% 充 盈 ， 另 外 b/2 数 量 的 数据 块 为 50% 充 盈 ， 则 该 区 段 的 加 权 空 闲 数据 块 数 


量 为 bx (25%+ 50%) /2。 当 然 这 是 一 种 近似 的 算法 ， 但 是 比 只 统计 空闲 数据 块 为 碎片 要 准确 得 多 ， 后 面 


实际 的 测试 情况 也 会 充分 说 明 该 方法 是 可 以 信任 的 。 


表 3-2 分 析 表 碎片 分 布 情况 
空闲 度 数据 块 数 
0 ~ 25% a 
25% ~ 50% b 


d 


加 权 空 闲 数据 块 数 


a*(0 十 25%)/2 

b*(25% 十 50%)/2 
c*(50% 十 75%)/2 
d*(75% 十 100%)/2 


以 上 过 程 是 统计 未 完全 填充 的 数据 块 的 碎片 情况 ， 对 于 完全 空闲 的 数据 块 ， 我 们 还 需要 另外 再 统计 一 次 。 同 样 使 
所 示 ， 此 处 的 加 权 空 闲 数据 块 数量 就 是 其 实际 空闲 数据 块 的 数量 。 


DBMS SPACE.UNUSED_SPACE 分 析 目 标 表 ， 获 取 完 全 空闲 的 数据 块 数量 。 如 表 3-3 


表 3-3 分析 表 的 空闲 数据 块 
空闲 度 数据 块 数 加 权 空 闲 数据 块 数 
100% e e*100% 


加 权 计算 结果 汇总 : 


段 的 真实 大 小 一段 大 小 一 〈 以 上 各 区 段 “ 加 权 空闲 数据 块 数 ” 的 和 ) X 数 据 库 数据 块 大 小 


注意 : 段 大 小 即 为 DBA_SEGMENTS 视 图 


中 对 应 段 的 BYTES 字 段 加 和 值 。 


is 如 果 判 断 是 分 区 表 ， 则 需要 按 以 上 方法 逐个 扫描 所 有 分 区 。 


下 面 我 们 也 提供 一 个 自 定义 函数 REAL SIZE 来 实现 以 上 的 表 碎 片 率 统计 的 方法 论 ， 如 果 目 标 表 是 分 区 表 ， 则 需要 对 以 下 函数 进行 适当 的 改写 。 


CREATE OR REPLACE FUNCTION REAL SIZE(P SEGNAME IN VARCHAR2, 
POWNER IN VARCHAR2 DEFAULT USER, 
P_TYPE IN VARCHAR2 DEFAULT 'TABLE') 
RETURN NUMBER AUTHID CURRENT USER RS 


L_TOTAL, BLOCKS NUMBER; 
L_TOTAL BYTES NUMBER; 
L UNUSED BLOCKS NUMBER; 
L_UNUSED BYTES NUMBER; 
L LASTUSEDEXTFILEID NUMBER; 
L LASTUSEDEXTBLOCKID NUMBER; 
LLAST USED BLOCK NUMBER; 
L UNFORMATTED BLOCKS NUMBER; 
L UNFORMATTED BYTES NUMBER; 
LFS1 BLOCKS NUMBER; 
L FS1 BYTES NUMBER; 
L FS2 BLOCKS NUMBER; 
L FS2_BYTES NUMBER; 
L_FS3_ BLOCKS NUMBER; 
LFS3_BYTES NUMBER; 
L FS4 BLOCKS NUMBER; 
L FS4 BYTES NUMBER; 
L_FULL BLOCKS NUMBER; 
LFULL BYTES NUMBER; 
T_TOTAL BYTES NUMBER; 
TFS BYTES NUMBER; 
Pp_PART NAME VARCHAR2 (30) ; 

BEGIN 
DBMS_SPACE. SPACE USAGE (P_OWNER, 

P_SEGNAME, 
Pp_TYPE, 
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L LASTUSEDEXTFILEID, 
L LASTUSEDEXTBLOCKID, 


L LAST USED BLOCK, 
P_PART NAMP] ; 

T_FS BYTES := LFS] BYTES * 0.25 / 2 + L FS2 BYTES * (0.5 + 0.25) / 2 + 

J LL Poy BYTES * {075+ 05 7 芝 直 


L FS4 BYTES * (1 + 0.75) / 2 + L UNUSED BYTES; 
T_TOTAL BYTES := L TOTAL BYTES; 
RETURN T_TOTAL BYTES - T_FS BYTES; 
EXCEPTION 
WHEN OTHERS THEN 
RETURN - 1; 
END; 


接 下 来 ， 使 用 REAL_SIZE 函 数 来 看 看 效果 ， 拿 前 面 制造 了 碎片 的 表 alex_t37 来 做 个 测试 吧 。 


率 约 为 24.519%。 


SQL> select trunc (real size('RLEX T37') / 1024 / 1024, 2) real size, 
2 bytes / 1024 / 1024 seg : size, 
trunc ((1 - real size('ALEX T37') / bytes) * 100, 2) 
11 '%' frag ratio 
from dba_segments 
where segment name = 'ALEX T37'; 
REAL SIZE SEG SIZE FRAG RATIO 


60.38 80 24.51% 


4 
号 
6 


这 个 统计 分 析出 来 的 24.51% 的 碎片 率 是 否 准确 呢 ? 我 们 还 需要 验证 一 下 看 看 。Oracle 数 据 库 从 10g 开 始 支 持 通过 shrink space 的 方式 对 表 进行 空间 回收 ， 


也 是 一 种 清理 碎片 的 好 方法 。 


看 到 DBA_SEGMENTS 中 识别 该 表 的 大 小 为 80MB， 通 过 函数 分 析 后 ， 


识别 该 表 大 小 为 60.38MB， 可 确认 碎片 


本 收 后 表 结构 基本 可 以 视 为 不 存在 碎片 了 ， 这 


通过 shrink space 整 理 后 的 表 ， 重 新 进行 REAL_SIZE 函 数 的 分 析 统计 ， 可 以 看 到 整理 后 的 碎片 率 仅 为 0.08%， 基 本 上 是 没有 碎片 了 。 同 时 ， 整 理 后 的 表 大 小 为 58.94MB， 对 比 整理 前 的 80MB 大 小 ， 可 以 
得 到 一 个 大 致 的 整理 前 碎片 率 为 (1-58.94/80) x100%= 26.33%。 这 与 统计 分 析出 来 的 碎片 率 24.51% 是 非常 接近 的 。 
SQL> alter table alex t37 enable row movement; 
SQL> alter table alex t37 shrink space; 
SQL> select trunc (real : Size('ALEX T37') / 1024 / 1024, 2) real size, 
名 bytes / 1024 / 1024 Seg size, 
3 trunc((1 - real size('ALEX T37') / bytes) * 100, 2) 
4 11 5" frag_ratio 
Ss from dba_ segments 
6 where segment name = 'ALEX T37'; 
REAL SIZE SEG SIZE FRAG RATIO 
58.89 58.94 0.08% 
如 表 3-4 所 示 ， 使 用 REAL_SIZE 函 数 统计 计算 得 到 的 碎片 率 与 通过 shrink space 整 理 后 得 到 的 碎片 率 对 应 关系 。 随 着 记录 行 数 不 断 地 增 大 ， 表 大 小 不 断 地 增 大 ， 随 机 删除 一 定 的 行 数 制造 碎 
片 ，REAL _ SIZE 统计 的 碎片 率 的 偏差 程度 呈现 逐渐 变 小 的 趋势 ， 也 就 是 说 表 的 规模 越 大 ， 该 方法 准确 度 越 高 。 
表 3-4 REAL _ SIZE 函数 统计 碎片 率 偏差 
表 大 小 行 数 删除 行 数 整理 后 大 小 碎片 率 REAL SIZE REAL SIZE 
本 站 除 行 率 一 es 
(MB) (MB) (MB) 碎片 率 偏差 
12 102 082 6750 12 0.00% 11.11 7.42% 
104 918 747 60 750 100 3.85% 98.62 1.32% 
368 3 266 656 113 920 359 2.45% 337:l 0.51% 
1194 10 633 309 1 733 488 1016 14.91% 1004.32 0.98% 
2457 21 966 573 364 219 2434 0.94% 2426.29 0.32% 
2457 21 966 573 200 000 2457 0.00% 2456.2 0.03% 
2457 21 966 573 400 000 2455 0.08% 2453.31 0.07% 
2457 21966373 1 000 000 2417 1.63% 2414.98 0.08% 
2457 21 966 573 1 500 000 2348 4.44% 2346.08 0.07% 


既然 REAL_SIZE 统 计 计算 的 方法 准确 率 很 高 ， 又 很 快捷 ， 是 否 可 以 用 在 索引 的 碎片 分 析 上 呢 ， 毕 竟 都 是 Oracle 的 段 嘛 ? 


先 来 尝试 一 下 看 看 吧 ， 对 表 alex_t38 新 建 一 个 在 object_name 列 上 的 单列 索引 ， 再 随机 删除 一 些 记 录 来 制造 表 碎片 和 索引 碎片 ， 然 后 进行 统计 分 析 。 如 下 所 示 : 


SQL> create index idx alex t38 name on alex t38 (object name); 
SQL> delete from alex t38 Where Object name like 'T%'; 
SQL> select trunc (real : Size("IDX ALFEX ' T38 NAME') / 1024 / 1024, 2) 
2 real size, 
3 bytes / 1024 / 1024 seg size, 
4 trunc((1 -~ real size('IDX ALEX T38 NAME') / bytes) * 100, 2) 
5 11 '%' frag ratio 
6 from dba_ segments 
7 where segment name = 'IDX ALEX T38_ NAME'; 
REAL SIZE SEG_SIZE FRAG :1 RATIO 


此 处 奇怪 地 发 现 索引 段 的 碎片 率 为 100%， 很 显然 这 是 完全 不 对 的 。 通 过 索引 结构 分 析 后 ， 得 


到 该 索引 的 碎片 率 为 7.589。 


SQL> analyze index idx alex t38 name validate structure; 
Index analyzed 
SQL> select height, 


2 round((del lf rows len/lf rows len)*100,2)||'%' ratio, 
3 pct used from index stats where name= 'IDX ALFX T38_ NAME'; 
HEIGHT RATIO PCT_USED 
3 7.58% 90 


为 什么 会 这 样 呢 ? 是 因为 表 和 索引 的 组 织 结构 是 完全 不 一 样 的 ， 表 是 堆 表 的 形式 ， 是 随机 无 序 存储 的 ， 而 索引 是 树 形 有 序 存储 的 。 另 外 ， 表 上 的 数据 删除 是 确实 的 数据 删除 ， 而 索引 的 条 目 删除 只 是 标 


示 了 一 下 ， 并 没有 真正 删除 ， 这 一 点 也 是 不 同 的 。 即 使 它们 都 没有 回收 空间 ， 但 是 索引 上 是 无 法 使 用 DBMS_SPACE 来 分 析 碎片 的 。 


3.7.3 ”碎片 的 整理 


关于 表 碎 片 整理 的 方法 ， 其 实 和 前 面 介 绍 的 行 迁移 清理 的 方法 差不多 ， 包 括 : 
“ 通过 EXP/IMP 或 者 EXPDP/IMPDP， 导 出 /导入 数据 表 ; 
:ALTER TABLE MOVE; 


“ 表 在 线 重 定义 。 


简单 地 说 ， 其 方法 都 是 一 个 主导 思想 ， 将 表 整 个 结构 上 重建 一 下 。 说 到 这 和 
论 使 用 的 是 上 述 哪 种 方法 ， 都 会 面临 着 三 个 动作 : 


时 ， 很 容易 会 联系 到 索引 的 


E 建 ， 那 是 一 个 比较 繁琐 且 影 响 很 大 的 操作 ， 相 比 之 下 ， 表 的 “ 宣 


量 建 ”将 有 过 之 而 无 不 及 。 因 为 不 


“ 表 结 构 的 重新 创建 ， 包 括 关联 约束 等 ; 
“ 数据 的 重新 建立 或 者 数据 的 迁移 ; 


“ 全 部 索引 的 重建 。 


可 以 说 这 样 的 操作 是 风险 非常 高 的 了 ， 不 到 万 不 得 已 相信 很 少 有 人 愿意 去 这 么 了 
题 ， 高 并 发 的 压力 同样 会 导致 不 可 挽回 的 后 果 。 这 确实 是 一 个 两 难 的 问题 。 


FF 的。 不 幸 的 是 往往 需 


考虑 碎片 整理 的 表 又 都 是 业务 压力 比较 大 、 并 发 度 比较 高 、 容 量 比较 大 的 表 ， 如 果 不 解决 碎片 问 


1.SHRINK SPACE 


从 Oracle 10g 开 始 ， 数 据 库 提 供 了 表 空 间 整理 的 功能 ， 正 是 前 面 说 到 的 SHRINK SPACE 的 方式 。 下 面 我 们 将 全 面 解读 一 下 该 功能 
如 图 


3-20 所 示 ， 一 次 完整 的 SHRINK SPACE 操 作 ， 基 本 上 可 以 分 为 三 个 主要 阶段 和 一 个 可 选 阶段 : 


: 第 一 个 阶段 ， 先 确定 开启 了 目标 表 的 行 移动 功能 。 语 自如 : ALTER TABLE<table_name>ENABLE ROW MOVEMENT。 同 时 ， 表 空间 管理 方式 必须 为 ASSM。 
“ 第 二 个 阶段 执行 压缩 。 在 此 阶段 ， 行 将 尽 可 能 移动 到 段 的 左 侧 部 分 。 行 将 在 内 部 移动 ， 以 避免 锁定 问题 。 语 自如 : ALTER TABLE<table_name>SHRINK SPACE COMPACT。 


第 三 阶段 启动 收缩 操作 。 将 调整 高 水 位 标记 (HWM) ， 并 释放 未 使 用 的 空间 。 语 句 如 : ALTER TABLE<table_name>SHRINK SPACE。 


可 选 阶段 回收 相关 索引 空间 ， 这 个 可 做 可 不 做 。 语 自如 : ALTER TABLE<table_name>SHRINK SPACE CASCADE。 


! HWM 


°° 一 一 
e@ 三 三 -一 一 


e 司 了 


图 3-20 SHRINK SPACE 原 理 


如 果 有 长 时 间 运 行 的 查询 可 能 跨越 收缩 操作 ， 并 尝试 从 已 回收 的 块 中 读 取 ， 则 COMPACT 子 句 会 很 有 用 。 指 定 SHRINK SPACE COMPACT 子 句 时 ， 收 缩 操作 的 进度 将 保存 在 相应 段 的 位 图 块 中 。 这 意味 
着 下 次 在 同一 个 段 上 执行 收缩 操作 时 ，Oracle 数 据 库 能 够 记 住 已 经 执行 过 的 操作 。 然 后 就 可 以 在 非 峰值 时 段 重新 发 出 SHRINK SPACE 子 句 ， 而 无 须 COMPACT 子 句 即 可 完成 第 二 阶段 。 值 得 一 提 的 
是 ，SHRINK SPACE 的 数据 的 移动 机 制 ， 既 然 Oracle 是 从 后 向 前 移动 行 数据 ， 那 么 SHRINK SPACE 的 操作 就 不 会 像 MOVE TABLE 一 样 ， 它 不 需要 使 用 额外 的 空闲 空间 。 


SHRINK SPACE 这 么 强大 ， 是 不 是 很 好 奇 它 到 底 是 如 何 工作 呢 ? 下 面 我 们 通过 一 个 实例 来 看 一 下 吧 ， 它 真 的 是 那么 完美 的 吗 ? 


步骤 1 整理 好 表 alex_t37 的 碎片 后 ， 再 在 该 表 上 进行 大 量 的 delete 操 作 ， 来 制造 新 的 碎片 ， 记 住 这 里 我 们 实际 删除 的 记录 行 数 : 


SQL> delete from alex t37 where object name like "TY'"7 
37680 rows deleted 


步骤 2 新 开 一 个 会 话 ， 执 行 shrink space 的 操作 ， 监 控 该 过 程 产生 的 REDO 日 志 量 : 


SQL> select b.name, a.value 
2 from VS$mystat a, v$statname Pb 
3 where a.statistic# = b.statistic# 
4 and b.name = 'redo size'; 


redo size 2160 
SQL> alter table alex t37 shrink space; 
Table altered 
SQL> select b.name, a.value 
2 from VS$mystat a, v$statname b 
3 where a.statistic# = b.statistic# 


4 and b.name = 'redo size'; 
NAME. VALUE 
redo size 80128512 


在 shrink space 过 程 中 ， 同 时 监控 到 对 表 产生 了 锁 。 


SQL> select * from v$locked object; 
XIDUSN XIDSLOT XIDSQN OBJECT ID SESSION ID PROCESS LOCKED MODE 


15 8 2483076 312787 1380 27800:25080 3 


看 到 这 里 ， 是 不 是 开始 有 些 担心 了 呢 ? 区 区 一 个 shrink space 怎 么 会 产生 这 么 大 的 REDO 日 志 量 呢 ， 而 且 还 会 锁 表 ? 我 们 继续 来 一 探究 竟 吧 。 


步骤 3 ”通过 挖掘 神器 Log Miner 来 分 析 一 下 在 线 重 做 日 志 ， 当 前 日 志 为 “redo01.log” : 


SQL> exec dbms logmnr.add logfile('/redolog/redo01.1og'，dbms logmnr.new) 
SQL> exec dbms logmnr.start logmnr (options => dbms logmnr.dict from online catalog) 


步骤 4 ”分析 一 下 与 表 alex_t37 相 关 的 条 目 ， 惊 奇 地 发 现 居然 有 12 万 多 条 ， 步 又 1 中 的 DELETE 操 作 也 只 不 过 删除 了 不 到 4 万 条 的 记录 行 ; 


SQL> select count (*) from v$logmnr contents 
2 where sql redo like '%ALEX T37%'; 
COUNT (*) 


121534 


步骤 5 ”非常 惊讶 地 发 现 这 12 万 多 的 条 目 都 是 在 delete 和 insert 的 操作 ; 


SQL> select sql redo from v$logmnr contents 
2 where sql redo like '%ALEX T37%'; 
SQL REDO 


delete from ", "ALEX T37" ROWID = 'AABMXXAAEAAACP8AAA'; 
insert into ™ . "ALEX_ T37" ("™ 

delete from ", " "ALEX T37" ROWID = 'AABMXXAAEAAACP8AAB'; 
insert into ", "."ALEX T37™("™ 


delete from ", "ALEX T37" .» ROWID = "AABMXXAAFEAAACP8AAC'; 


insert into " EX_T37 

delete from ", EX T37 = 'AAPMXXAAFAAACP8AAD'; 
insert into " EX T37 

delete from ", ALEX_T37 = 'AABMXXAAFAAACP8AAE'; 
insert into ™, "NATEX TS37"(" 

delete from ", "ALEX T37" = 'AABMXXAAFAAACP8AAF'; 
insert into ™", "ALEX_T37" (" 

delete from ", EFEX T37 = 'AAPMXXAAFAAACP8AAG'; 
insert into " EX_T37 

delete from ", .ALEX T37" = 'AABMXXAAFAAACP8AAH'; 


通过 以 上 的 分 析 ， 我 们 不 难得 出 一 个 结论 : SHRINK SPACE 的 实质 就 是 在 表 的 内 部 通过 一 个 事务 ， 获 取 表 的 锁定 ， 再 不 断 地 
奇怪 了 。 


因此 ， 我 们 也 可 以 总 结 出 一 些 使 用 SHRINK SPACE 功 能 的 次 端 : 


“ SHRINK SPACE 是 通过 事务 来 内 部 处 理 表 的 数据 ， 同 样 会 持 有 锁 ， 操 作 期 间 会 影响 表 的 正常 使 用 。 


DELETE 和 INSERT 移 动 数据 行 。 这 样 在 步骤 2 中 产生 大 量 的 REDO 日 志 也 就 不 


` SHRINK SPACE 实 质 是 一 系列 的 DELETE 和 INSERT 操 作 ， 会 产生 大 量 的 REDO 上 日志， 会 造成 LGWR 进 程 的 压力 ， 可 能 会 造成 归档 空间 不 足 。 


既然 SHRINK SPACE 功 能 有 这 么 些 浆 端 ， 那 干脆 不 要 用 好 了 ? 那 也 大 可 不 必 ， 对 于 容量 比较 小 或 者 业务 并 发 压力 比较 小 的 表 
来 的 风险 。 


然而 ， 对 于 一 个 高 并 发 的 表 来 说 ，SHRINK SPACE 可 能 不 一 定 是 个 好 的 选择 。 


2.ALTER TABLE MOVE 


， 可 以 在 空闲 时 段 使 用 该 功能 ， 还 是 相对 方便 的 ， 可 以 避免 过 多 人 工 操作 带 


在 实际 的 应 用 当中 ，DBA 们 更 倾向 于 使 用 ALTER TABLE MOVE 的 方法 ， 先 将 目标 表 移 动 到 一 个 中 转 的 表 空间 ， 再 移动 回来 ， 


并 重建 所 有 相关 索引 。 


步骤 1 将 表 alex_t37 移 动 到 中 转 表 空间 user_migrate， 再 将 其 移 回 去 ， 操 作 过 程 中 ， 对 表 会 添加 一 个 排他 锁 。 


SQL> alter table alex t37 move tablespace user migrate; 
Table altered SS 

SQL> alter table alex t37 move tablespace users; 

Table altered 加 


如 果 表 对 表 空 间 没有 过 多 依赖 的 话 ， 也 可 以 不 要 移动 回 原来 的 表 空间 。 但 是 ， 大 部 分 数据 库 中 ， 都 是 按照 不 同 的 子 系统 应 


来 区 分 存储 的 表 空 间 的 。 这 是 对 之 前 分 散 VO 应 用 习惯 的 继承 ， 也 是 为 了 便于 


管理 ， 尽 可 能 地 保证 表 空间 之 间 相 对 独立 ， 能 够 使 单个 表 空 间 实现 自 包含 ， 这 样 可 以 比较 方便 地 使 用 传输 表 空间 的 方式 来 做 数据 


步骤 2 ”重建 目标 表 上 索引 。 


库 迁 移 等 。 


SQL> select index name, status from dba indexes 
2 where index name='IDX ALEX T37 ID'; 

INDEX_ NAME srvs 

IDX ALEX T37_ID UNUSABLE 

SQL> alter index idx alex t37 id rebuild online; 

Index altered es 

SQL> select index name, status from dba indexes 
2 where index name='IDX ALEX T37 ID™; 

INDEX_ NAME ”TsTATUS 


IDX ALEX T37_ID VALID 


可 以 看 到 表 发 生 表 空间 移动 后 ， 其 上 的 索引 变 得 不 可 用 了 。 如 果 表 没有 数据 ， 索 引 是 不 会 失效 ， 当 然 如 果 没 有 数据 ， 以 上 动 


作 我 们 也 都 不 必 去 做 了 。 


当 表 发 生 移动 的 时 候 ， 其 上 的 数据 物理 存储 结构 也 全 部 发 生 了 变化 ， 直 接 导致 数据 行 的 ROWID 发 生 了 变化 。 而 索引 则 是 一 个 ROWID 的 “管理 中 心 ”，ROWID 全 都 不 对 了 ， 那 么 这 个 “管理 中 心 ” 也 就 


无 效 了 ， 索 引 变 得 不 可 用 ，Oracle 标 记 其 为 UNUSABLE。 索 引 重 建 后 ， 该 问题 将 被 修复 。 


3. 在 线 重 定义 


如 果 既 接受 不 了 SHRINK SPACE 造 成 的 REDO 日 志 压力 ， 也 接受 不 了 ALTER TABLE MOVE 造 成 的 离线 时 间 ， 可 以 选择 在 线 寻 


下 面 我 们 通过 一 个 实例 来 介绍 一 下 在 线 重 定义 表 的 应 用 吧 。 


定义 表 的 方式 来 做 。 


步骤 1 备份 重 定义 表 的 统计 信息 ， 在 所 有 操作 完成 后 可 以 恢复 该 时 点 的 统计 信息 ， 保 证 性 能 不 损耗 ， 如 果 有 不 同 的 收集 策略 ， 可 以 考虑 不 做 备份 。 


SQL> exec dbms_stats.create stat table (ownname => 'ALEX', stattab => 'ALEX T37_STAT') 


SQL> BEGIN 
2 dbms_ stats.export table stats (ownname => 'ALEX', 
3 tabname => 'ALEX T37°', 
4 stattab => 'ALEX T37_STAT', 
5 statown 'ALEX', 
6 cascade TRUE, 
7 statid 'ALEX_T37_REDEF'); 
8 
9 END; 
了 这 
步骤 2 ”检查 是 否 可 以 进行 重 定义 ， 需 要 保证 目标 表 是 有 主键 的 ， 因 为 在 线 重 定义 过 程 要 基于 主键 来 刷新 同步 数据 。 


SQL> exec dbms redefinition.can redef table('ALEX','ALEX T37') 


步骤 3 ”创建 目标 表 的 临时 表 ， 保 证 与 原 表 结构 一 致 ， 如 果 需 要 保证 初始 化 数据 同步 的 效率 ， 可 以 在 步骤 4 之 后 再 创建 索引 。 


SQL> create table ALEX T37_TMP 


县 

3 OWNER VARCHAR2 (30) ， 
4 OBJECT NAME VARCHAR2(128), 
5 SUBOBJECT NAME VARCHAR2 (30), 
6 OBJECT ID NUMBER, 

7 DATA OBJECT ID NUMBER, 

8 OBJECT TYPE VARCHAR2(19), 
9 CREATED DATE, 

10 LAST DDL TIME DATE, 
这 TIMESTRAME VARCHAR2 (19) ， 
12 STATUS VARCHAR2 (7) ， 
13 TEMPORARY VARCHAR2 (1) ， 
14 GENERATED VARCHAR2 (1) ， 
15 SECONDARY VARCHAR2 (1) 
16 ); 


SQL> alter table alex t37 tmp add constraint NN ALEX T37 NAME TMP 
2 check (OBJECT NAME IS NOT NULL); 
SQL> create index IDX ALEX T37 NAMP TMP on ALEX T37 _ TMP (OBJECT NAME); 


步骤 4 ”开始 在 


重 定义 ， 完 成 物化 视图 创建 ， 并 通过 物化 视图 进行 数据 初始 化 。 


SQL> exec dbms redefinition.start redef table (uname => 'ALEX', 

orig table => 'ALEX T37',int table => 'ALEX T37 TMP') 
SQL> select owner, mview name from User mviews; > 
MVIEW NAME 


OWNER 


ALEX_T37_TMP 


步骤 5 ”复制 原 表 上 的 依赖 对 象 ， 包 括 约 束 、 触 发 器 、 权 限 等 ， 保 持 跟 原 表 完 全 一 致 ， 设 置 copy_indexes 为 0 表示 不 复制 索引 ， 提 高 效率 。 


SQL> DECLARE 
受 retval NUMBER(5); 
3 BEGIN 
4 Gbms_ redefinition.copy table dependents( 
允 uname => 'ALEX', 
6 orig table 'ALEX T37°', 
7 int_table 'ALEX_T37_TMP', 
8 copy_indexes 0， 
9 copy triggers TRUE, 
10 copy_constraints TRUE, 
11 copy privileges => TRUE, 
12 ignore errors => TRUE, 
13 num errors => retval); 
14 dbms output.put line (retval); 
15 END; 
16 / 
步骤 6 注册 新 建立 的 索引 ， 因 为 我 们 没有 复制 索引 ， 而 是 手动 创建 索引 ， 因 此 我 们 需要 执行 register dependent_object 过 程 注册 索引 信息 。 该 过 程 的 作用 是 将 新 建 的 依赖 对 象 名 与 原 表 中 相应 的 依赖 


对 象 名 之 间 建 立 对 应 关系 ， 以 便 保持 各 类 依赖 对 象 的 名 称 不 变 。 


SQL> declare 


2 V_Ppk name varchar2 (30) 7 
3 begin 
4 Gbms_redefinition.register dependent object( 
5 uname => 'ALEX', 
6 orig table 'ALEX _T37', 
7 int_table 'ALEX T37 TMP'"， 
8 dep type DBMS REDEFINITION.CONS_ INDEX, 
9 dep_owner 'ALEX', 
10 dep orig name => 'IDX ALFEX T37 NAME', 
1 dep int name => 'IDX ALEX T37 NAME TMP'); 
12 end; 
13 7 
步骤 7 ”因为 选择 不 复制 索引 ， 但 复制 了 主键 ，Oracle 会 自动 建立 一 个 TMP$$_PK 前 缀 的 主键 索引 ， 也 需要 手工 注册 一 下 。 


SQL> declare 
V_pk name 
begin 
select index name into v pk name 
from dba indexes 
where owner="'ALEX"' 
and table name='ALEX T37 TMP' 
and index name like 'TMP$$ PK%'; 
dbms_redefinition.register dependent object( 


Varchar2 (30); 


2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 


Uname => 'ALEXT, 
orig table => 'ALEX T37', 
int_table => 'RLEX T37 TMP'， 
dep type DBMS REDEFINITION.CONS INDEX, 
dep_owner 'ALEX', 
dep_orig name => 'PK ALEX T37', 
Gep int name => Vv pk name); 
end; 
/ 


步骤 8 刷新 数据 并 完成 原 表 和 TMP 的 切换 ，sync_interim_table 需 
须 保证 执行 过 程 中 业务 离线 ， 也 可 以 说 该 步骤 执行 的 时 间 就 是 整个 在 线 


反复 多 次 执行 ， 保 证 数据 完全 一 致 后 再 执行 finish_redef table 完 成 切换 ， 最 后 确认 无 误 后 删除 TMP 表 。 这 个 步骤 是 最 关键 的 ， 必 
定义 表 的 要 求 离线 时 间 。 


SQL> exec dbms redefinition.sync interim table( uname => 'ALEX', 


orig table => 'ALEX T37', int table 
SQL> exec dbms redefinition.finish redef table( 

orig table => 'ALEX T37', int _ table 
SQL> drop table ALEX.ALEX T37_ TMP; 四 


=> 'ALEX_T37_TMP') 
uname => 'ALEX', 
=> 'ALEX T37_ TMP') 


步骤 9 


清理 多 余 的 约束 ， 或 重 命名 名 称 不 对 的 约束 ， 然 后 恢复 备份 的 统计 信息 。 


SQL> begin 
2 Gbms_stats.import table stats (ownname => 'ALEX', 
3 tabname => 'ALEX T37', 
4 cascade => TRUE， 
总 stattab => 'ALEX T37 STRAT'， 
6 statid => 'ALEX T37_REDEF', 
可 statown => 'ALEX"'); 
8 end; 
9 


另外 ， 值 得 提 一 下 的 是 当 完成 了 在 线 重 定义 以 后 ， 原 来 ALEX_T37_ TMP 名 称 虽 然 变 成 ALEX_T37， 但 是 OBJECT_ID 仍 然 是 312914， 在 AWR 报 告 的 快照 表 中 ，312914 对 应 的 对 象 还 是 ALEX_T37_ TMP， 


没有 修改 ， 此 时 如 果 生 成 AWR 报 告 需要 注意 区 分 正确 的 表 名 。 


SQL> select owner, object name, object id 
2 from dba objects 
3 where object name = 'ALEX T3717 

OBJECT NAME OBJECT ID 

ALEX ALEX_T37 312914 

SQL> select owner, object name, obj# 

from dba hist seg stat obj 
3 where object name Tike "ALEX T37%'; 


OWNER OBJECT NAME OBJ# 
ALEX ALEX_T37 312909 
ALEX ALEX_T37_TMP 312914 


综 上 所 述 ， 还 是 那 句 话 ， 各 种 方法 都 有 其 优 缺点 ， 还 是 需要 明确 风险 和 应 


[1] 《Expert One-on-One Oracle》 一 书 作 者 。 


3.8 ”本 章 小 结 


场景 ， 有 选择 的 去 实施 。 原 则 上 则 是 保证 最 小 化 风险 控制 。 


纵 观 本 章 ， 主 要 介绍 的 是 如 何在 Oracle 数 据 库 中 对 表 进 行 高 效 设计 和 维护 。 在 下 一 章 中 ,我们 将 给 读者 们 介绍 Oracle 最 核心 的 优化 器 、 统 计 信息 、 执 行 计划 的 高 效 设计 和 管理 。 


第 4 章 ”查询 优化 器 


本 章 要 点 : 
“ 优化 器 配置 ， 简 单 介绍 优化 器 的 种 类 、 配 置 管理 方法 。 
“ 像 优化 器 一 样 思考 ， 介 绍 优化 器 成 本 计算 的 工作 原理 。 
“ 统计 信息 管理 ， 介 绍 统计 信息 的 收集 与 管理 策略 。 


. 执行 计划 管理 ， 介 绍 如 何 获取 并 管理 较 优 的 执行 计划 。 


“ 性 能 影响 分 析 ， 介 绍 基于 优化 器 与 执行 计划 的 SQL 语句 性 能 影响 分 析 方 法 。 


“ 数据 库 重 放 ， 介 绍 如 何 使 用 数据 库 重 放 功 能 来 评估 数据 库 性 能 。 


在 前 面 两 章 关 于 索引 和 表 的 高 效 设计 与 使 
好 ， 高 并 发 处 理 设计 也 好 ， 都 不 可 避免 地 要 说 一 说 优化 器 。 


中 ， 我 们 反复 提 到 一 个 概念 就 是 优化 器 。Oracle 数 据 库 之 所 以 被 普遍 接受 ， 并 享有 很 高 的 地 位 ， 很 大 一 部 分 原因 就 是 优化 器 了 ， 这 里 我 们 说 到 性 能 优化 也 


优化 器 ， 也 叫 查询 优化 器 ， 它 的 功能 主要 就 是 将 一 些 通过 了 语义 分 析 的 可 读 的 SQL 语句 进行 转换 ， 并 根据 预先 收集 的 统计 信息 进行 SQL 语句 执行 过 程 的 成 本 评估 ， 最 后 产 出 最 优 的 执行 计划 ，SQL 语 句 最 
终 按 照 该 执行 计划 具体 执行 ， 查 询 优化 器 工作 效率 的 高 低 将 会 直接 决定 SQL 语句 执行 效率 的 高 低 。 从 某 种 意义 上 来 说 ， 本 章 的 内 容 也 可 以 叫做 高 效 SQL 语 句 的 设计 。 


然而 ， 优 化 器 的 工作 效率 并 不 完全 
SQL 语句 的 高 效 执行 ， 不 可 避免 地 需要 重视 并 合理 配 


、 管 理 此 三 要 素 : 
“ 查询 优化 器 

“ 统计 信息 

执行 计划 


执行 计划 是 查询 优化 器 产 出 物 ， 统 计 信 息 是 为 查询 优化 器 提供 


本 章 将 为 读者 介绍 查询 优化 器 、 统 计 信息 和 执行 计划 的 一 些 设计 、 使 


汉 决 于 其 自身 ， 还 将 依赖 于 统计 信息 。 可 以 这 么 说 ， 执 行 计划 决定 SQL 语 句 执行 的 效率 ， 优 化 器 决定 执行 计划 的 优 和 学 ， 统 计 信息 决定 优化 器 计算 的 准确 性 。 需 要 获得 


有 助 计算 的 工具 ， 可 以 说 三 要 素 中 最 重要 的 就 是 查询 优化 器 了 。 


4.1 优化 器 概述 


查询 优化 器 对 SQL 语句 执行 的 性 能 是 至 关 重要 的 ，SQL 语 句 执行 效率 高 了 ， 高 并 发 处 理 能 力 才 有 可 能 提升 。 因 


技巧 ， 立 足 于 分 享 一 种 方法 论 ， 不 一 定 具有 通 


性 ， 却 可 以 开拓 思路 ， 对 问题 的 思考 与 分 析 更 加 明确 。 


此 ， 多 花 一 些 时 间 在 合理 配置 查询 优化 器 上 是 非常 必要 的 。 


优化 器 的 内 容 是 非常 多 的 ， 也 是 非常 细 的 ， 我 们 不 可 能 通过 一 节 或 一 章 的 内 容 说 清楚 。 本 节 将 简 和 


优化 器 ， 相 关 参 数 是 如 何 作 


4.1.1 优化 器 简介 


介绍 一 下 RBO、CBO 优 化 器 ， 并 将 CBO 优 化 器 作为 展开 的 内 容重 点 ， 说 一 说 如 何 较为 合理 地 配置 CBO 
于 优化 器 的 ， 最 后 再 以 实例 的 方式 分 析 一 下 其 工作 的 原理 。 以 下 章节 提 及 的 优化 器 均 默 认为 CBO 优 化 器 。 


在 Oracle 数 据 库 中 ， 优 化 器 主要 分 为 RBO 和 CBO 两 种 ， 接 下 来 将 简单 介绍 一 下 这 两 种 优化 器 的 特点 和 工作 原理 。 


1.RBO 优 化 器 


在 开始 说 CBO 优 化 器 之 前 ， 先 来 说 说 RBO (Rule-Based Optimization) 优化 器 吧 。 顾 名 思 义 ， 这 是 一 个 基于 规则 的 优化 器 ，Oracle 在 基于 规则 的 优化 器 中 采用 启发 式 的 方法 或 规则 来 生成 执行 计划 。 
比如 : 一 个 查询 的 WHERE 子 句 中 包含 一 个 谓词 ， 且 该 谓词 上 引用 的 列 上 存在 有 效 索 引 ， 那 么 RBO 优 化 器 将 使 用 该 索引 访问 表 ， 而 不 考虑 其 他 因素 (例如 ， 数 据 的 多 少 、 数 据 的 可 变性 、 数 据 的 分 布 情况 、 索 
引 的 选择 性 等 ) 。 此 时 数据 库 中 不 必 存 在 关于 表 与 索引 的 统计 性 描述 信息 ， 即 表 与 索引 的 统计 信息 ， 即 便 存 在 ，RBO 优 化 器 也 将 无 视 之 。RBO 优 化 器 同时 也 不 会 考虑 实例 的 初始 化 参数 设置 情况 ， 例 如 ， 多 
块 读 的 I/O 情 况 、 可 用 的 排序 内 存 大 小 等 ， 所 以 RBO 优 化 器 有 时 就 略 带 盲目 地 生成 了 并 不 太 好 的 执行 计划 ， 导 致 系统 性 能 问题 。 


随 着 CBO 优 化 器 的 迅速 崛起 ， 从 Oracle 10g 版 本 开始 ，RBO 优 化 器 已 经 彻底 废 夺 了 。 而 仍然 奋战 在 Oracle 8 或 Oracle 9i 的 ， 或 多 或 少 的 都 还 有 机 会 磁 到 RBO 优 化 器 ， 因 此 有 必要 简单 介绍 一 下 这 个 略 
显 过 季 的 优化 器 的 工作 原理 。 


在 RBO 优 化 器 中 ，Oracle 根 据 可 用 的 访问 路 径 及 其 等 级 来 选择 执行 计划 ， 通 常 认 为 等 级 越 高 的 访问 路 径 运行 SQL 语句 越 慢 ， 如 果 一 个 语句 有 多 个 路 径 可 走 ，Oracle 总 是 选择 等 级 较 低 的 访问 路 径 。 


“1 级 : ROWID 定 位 单行 (Single Row byROWID) ; 


“2 级 : 群集 链接 定位 单行 (Single Row by Cluster Join) ; 

“3 级 : 带 有 唯一 键 或 主键 的 哈 希 徐 键 定位 单行 (Single Row by Hash Cluster Key with Unique or Primary Key) ; 
“4 级 : 唯一 键 或 主键 定位 单行 (Single Row by Unique or Primary Key) ; 

“5 级 : 群集 链接 (Clustered Join) ; 

“ 6 级 : 哈 希 徐 键 (Hash Cluster Key) ; 

“7 级 : 索引 著 键 (Indexed Cluster Key) ; 

“ 8 级 : 复合 索引 扫描 (Composite Index) ; 

“9 级 : 单列 索引 扫描 (Single-Column Indexes) ; 

“10 级 : 索引 列 进行 有 限制 范围 的 查询 (Bounded Range Search on Indexed Columns) ; 
"11 级 : 索引 列 进 行 无 限制 范围 的 查询 (Unbounded Range Seatch on Indexed Columns) ; 
“12 级 : 排序 合并 联 立 (Sort Merge Join) ; 


“ 13 级 : 索引 列 上 使 用 MAX 或 MIN 函 数 (MAX or MIN of Indexed Column) ; 


' 14 级 : 索引 列 上 使 用 ORDER BY 子 句 (ORDER BY on Indexed Column) ; 


“ 15 级 : 全 表 扫 描 (Full Table Scan) 。 


RBO 中 优先 级 最 低 的 是 全 表 扫描 ， 这 就 意味 着 Oracle 在 生成 SQL 语 句 的 执行 计划 时 ， 如 果 有 索引 可 以 利用 ， 即 使 全 表 扫 描 更 有 效率 ， 也 不 会 使 用 全 表 扫 描 。 这 也 是 大 家 通常 所 说 的 RBO 优 化 器 总 是 认为 
索引 最 优 的 原因 。 然 而 ， 很 多 情况 下 ， 事 实 并 非 如 此 。 具 体 的 案例 可 以 参考 第 2 章 中 的 介绍 。 


可 以 看 到 ，RBO 优 化 器 对 数据 并 不 敏感 ， 数 据 的 变化 不 会 影响 执行 计划 的 生成 ， 优 化 器 不 会 考虑 数据 的 多 少 、 数 据 分 布 、 索 引 的 选择 性 ， 等 等 。 换 一 个 思路 考虑 ， 这 样 的 特点 也 是 有 其 好 处 的 ， 只 要 建 
立 好 开发 管理 规范 ， 对 开发 人 员 进行 相关 培训 ， 强 制 按照 一 定 的 规则 来 书写 SQL 语句 ， 规 则 是 死 的 ， 是 便于 DBA 来 把 握 的 。 然 而 ， 也 正 因为 规则 是 死 的 ， 毫 无 灵活 性 可 言 ， 业 务 却 是 活 的 ， 没 有 办 法 不 变 应 
万 变 ， 最 终 导 致 RBO 优 化 器 的 没落 。 取 而 代 之 的 将 是 基于 成 本 的 CBO 优 化 器 。 


2.CBO 优 化 器 


如 图 4-1 所 示 ， 这 是 一 个 CBO 优 化 器 功能 组 件 和 工作 流程 的 大 致 结构 图 。 首 先 ， 一 个 经 过 分 析 (语义 分 析 ) 后 的 查询 进入 查询 转换 器 ， 经 过 转换 后 的 查询 再 被 发 送 至 评估 器 ， 数 据 字典 提供 预先 收集 的 
统计 信息 给 评估 器 作为 辅助 ， 然 后 查询 和 评估 结果 被 发 送 至 计划 生成 器 ， 计 划 生 成 器 将 执行 计划 返回 至 评估 器 ， 与 其 他 计划 进行 比较 。 这 是 一 个 反复 的 过 程 ， 优 化 器 将 测试 各 种 访问 路 径 、 联 立 顺序 和 方法 
以 确定 最 优 执 行 计划 ， 最 终 将 最 优 执 行 计划 发 送 至 行 源 生成 器 。SQL 语 句 的 结构 、 统 计 信息 准确 性 、 数 据 结构 和 参数 都 会 对 优化 器 产生 影响 ， 这 些 影响 因子 相互 之 间 会 有 非常 多 的 组 合 方式 ， 优 化 器 的 评估 
不 可 能 完全 覆盖 到 ， 所 以 优化 器 生成 的 执行 计划 未 必 就 是 最 优 的 ， 需 要 DBA 对 其 进行 干预 和 管理 。 


[ 


分 析 过 的 查询 


计划 生成 需 


执行 计划 


图 4-1 CBO 优 化 器 组 件 


可 以 看 到 CBO 优 化 器 自身 是 由 三 大 组 件 构 成 的 ， 下 面 我 们 来 逐一 介绍 一 下 : 
“ 查询 转换 器 
“ 评估 器 
“ 计划 生成 器 


(1) 查询 转换 器 


查询 转换 器 的 输入 是 一 个 经 过 分 析 的 查询 ， 查 询 语句 的 形式 会 影响 所 产生 的 执行 计划 ， 查 询 转换 器 的 作用 就 是 改变 查询 语句 的 形式 来 产生 最 优 的 执行 计划 。 


Oracle 提 供 了 四 种 转换 技术 : 


“ 视图 合并 (View Merging) 


' 谓词 推进 (Predicate Pushing) 


“ 非典 套子 查询 (Subquery Unnesting) 


“ 物化 视图 的 查询 重 写 (Query Rewtite with Matetialized Views) 


(2) 评估 器 


评估 器 通过 计算 三 个 值 来 评估 计划 的 总 体 成 本 。 


“ 选择 度 (Selectivity) : 是 一 个 大 于 0 小 于 1 的 数 ， 也 可 以 视 为 一 个 比率 ，0 表 示 没 有 记录 被 选 定 ，1 表 示 所 有 记录 都 被 选 定 。 这 个 概念 在 第 二 章 的 索引 设计 中 已 经 介绍 过 了 ， 这 里 不 重复 展开 了 。 


“ 基数 (Cardinality) : 表示 行 源 中 的 行 数 量 。 这 里 的 行 源 可 以 是 表 、 视 图 ， 也 可 以 是 联 立 后 子 查询 结果 集 。 如 果 对 一 个 表 执 行 全 表 扫描 ， 则 表 就 是 行 源 ， 而 基数 就 是 该 表 的 行 数 。 


“成 本 (Cost) : 就 是 度量 资源 消耗 的 单位 。 一 个 查询 耗费 的 资源 可 以 被 分 成 3 个 基本 组 成 部 分 : I/O 成 本 、CPU 成 本 、 网 络 成 本 。I/O 〇 成 本 是 将 数据 从 磁盘 读 入 高 速 缓 存 内 存 区 域 所 需 的 代价 。 在 一 般 情 
况 下 ， 该 成 本 是 处 理 一 个 查询 所 需要 的 最 主要 成 本 ， 所 以 优化 的 一 个 基本 原则 就 是 降低 查询 所 产生 的 I/ 〇 次数。CPU 成 本 是 处 理 在 内 存 中 数据 所 需要 的 代价 。 对 于 需要 访问 跨 节 点 数据 库 的 查询 来 说 ， 就 存在 
网 络 成 本 ， 用 来 量化 传输 操作 耗费 的 资源 。 


(3) 计划 生成 器 


简单 地 说 ， 计 划 生 成 器 的 主要 功能 是 为 给 定 的 查询 测试 不 同 的 可 能 计划 ， 然 后 挑选 一 个 成 本 最 低 的 计划 作为 查询 的 执行 计划 输出 。 关 于 执行 计划 的 解读 在 本 章 的 第 4.4 节 会 展开 介绍 。 


从 另 一 方面 来 说 ， 执 行 计 划 反 映 的 是 最 优化 的 成 本 评估 结果 ， 评 价 一 个 执行 计划 的 好 坏 ， 很 大 程度 上 是 从 成 本 开销 上 来 决定 的 。 


下 面 是 一 个 执行 计划 的 例子 ， 最 重要 的 一 个 指标 就 是 “Cost (%CPU) ”这 个 栏 位 ， 反 映 的 就 是 评估 器 计算 出 来 的 最 优 执行 计划 的 成 本 开销 ， 而 “Rows” 栏 位 反映 的 是 基数 。 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 479K| 89M| 4455 (1)1 
I* 1 | HASH JOIN | 中 479K| 89M| 4455 人 站 
[ 2 | TABLE ACCESS FULL| ALEX T37 | 61536 | 6129KI 211 S| 
| 3 1 TABLE ACCESS FULL| ALEX T38 | 479K| 42M| 1499 (2) | 


现在 我 们 可 以 说 优化 器 中 核心 组 件 就 是 评估 器 了 ， 而 评估 器 最 重要 的 指标 是 成 本 开销 ， 要 想 优化 执行 计划 ， 就 要 降低 其 COST 成 本 开销 。 这 个 工作 可 以 主要 从 MO 开销 和 CPU 开销 两 个 方面 展开 ， 网 络 成 
本 的 开销 在 非 跨 节点 数据 库 操作 中 可 以 忽略 。 


4.1.2 ”参数 配置 


说 到 配置 ， 首 先 需要 做 的 当然 也 是 CBO 优 化 器 相关 参数 的 配置 了 。 可 能 首先 映 入 大 脑 的 是 那么 几 个 比较 常用 的 参数 ， 毕 竟 配 置 好 就 能 不 错 的 工作 了 。 即 便 不 作 任何 配置 ， 其 实 优化 器 工作 得 也 还 行 的 ， 
这 是 因为 初始 化 参数 的 默认 值 都 是 Oracle 已 经 优化 配置 过 的 ， 具 有 一 定 的 通用 性 ， 我 们 在 个 性 化 使 用 中 也 尽 可 能 保持 “最 优化 现状 ”原则 ， 即 接受 现状 的 配置 ， 就 不 要 轻易 去 修改 相关 参数 。 有 很 多 书籍 和 
文档 中 ， 鼓 励 大 家 去 多 多 配置 相关 的 参数 ， 我 们 说 参数 配置 也 是 过 犹 不 及 的 ， 只 要 配置 好 需要 的 几 个 即 可 。 下 面 我 们 来 看 看 哪 几 个 是 常用 的 ， 值 得 多 关注 的 。 


1.OPTIMIZER_MODE 


该 参数 算是 一 个 老生 常 谈 的 参数 了 ， 但 其 设置 不 容 小 凯 ， 其 可 设置 优化 器 以 确定 最 优 计划 的 方法 。 具 体 如 下 : 


“ CHOOSE: 默认 值 。 根 据 实际 情况 ， 如 果 数 据 字典 中 包含 被 引用 的 表 的 统计 数据 ， 就 使 用 CBO 优 化 器 ， 否 则 为 RBO 优 化 器 。 如 果 有 三 张 引用 表 ， 只 要 其 中 一 张 有 统计 信息 数据 ， 也 是 会 使 用 CBO 优 化 
器 的 。 


“RULE: RBO 优 化 器 。 建 议 不 要 使 用 。 


“ALL_ ROWS: CBO 优 化 器 使 用 的 优化 方法 ， 是 以 数据 的 吞吐 量 为 主要 目标 ， 以 便 可 以 使 用 最 少 的 资源 完成 语句 。 在 没有 特殊 应 用 的 情况 下 ， 推 荐 使 用 该 方法 ， 在 实际 使 用 中 ， 其 更 能 体现 出 CBO 优 化 
器 的 优势 。 


“FIRST ROW: CBO 优 化 器 使 用 的 优化 方法 ， 是 以 数据 的 响应 时 间 为 主要 目标 ， 以 便 快 速 查询 出 开始 的 几 行 数据 ， 其 更 偏向 于 使 用 索引 。 


“FIRST_ ROWS_[1110110011000]: 该 方法 是 对 FIRST_ROW 方 法 的 扩展 ， 以 迅速 产生 查询 结果 的 前 N 行 。 该 参数 为 Oracle 9i 新 引入 的 。 


值得 注意 的 是 ， 不 管 该 参数 设置 如 何 ， 以 下 三 种 情况 一 定 会 使 用 CBO 优 化 器 : 


“ 在 Oracle 10g 以 后 ，RBO 优 化 器 不 被 支持 了 ， 其 新 增 的 一 些 结构 ， 如 索引 组 织 表 (IOT) 等 ，RBO 优 化 器 不 能 识别 ， 会 自动 使 用 CBO 优 化 器 ; 
: Oracle 7.3 以 后 ， 如 果 表 上 的 并 行 度 大 于 1， 也 会 自动 使 用 CBO 优 化 器 ， 无 视 RULE 相 关 的 HINT 关 键 字 ; 


“ 使 用 RUIE 以 外 的 任何 HINT 关 键 字 ， 其 都 将 自动 使 用 CBO 〇 优化 器 。 
2.DB_ FILE MULTIBLOCK READ COUNT 


此 参数 看 似 与 CBO 优 化 器 没有 关系 ， 却 是 影响 非常 大 的 。CBO 优 化 器 在 做 成 本 计算 时 将 非常 依赖 该 参数 的 设置 。 在 全 表 扫 描 或 索引 快速 全 扫描 时 ，Oracle 使 用 到 的 最 大 |/O 取 决 于 
DB_FILE_MULTIBLOCK_READ_COUNT 与 DB_BLOCK_SIZE 的 乘积 。 对 于 一 个 数据 库 来 说 ， 后 者 基本 上 是 可 以 视 为 固定 的 ， 也 就 是 说 DB_FILE_MULTIBLOCK_READ_COUNT 决 定 了 最 大 I/O 单 元 ， 直 接 影响 
估计 全 表 扫 描 和 索引 快速 全 扫描 的 成 本 。 值 越 大 ， 全 表 扫 描 的 估计 成 本 就 越 低 ， 这 会 导致 优化 器 选择 全 表 扫 描 ， 而 不 选择 索引 扫描 。 在 有 可 能 的 条 件 下 ， 我 们 尽 可 能 地 将 该 参数 设置 大 一 些 ， 以 获取 更 好 的 
I/O 性 能 。 


下 面 来 看 一 个 测试 例子 ， 分 析 一 下 该 参数 对 全 表 扫 描 成 本 计算 的 影响 。 当 该 参数 的 值 设 置 得 比较 小 的 时 候 ， 其 执行 计划 的 COST 开 销 会 比较 大 ， 实 际 执行 时 间 也 比较 长 。 


SQL> alter session set db file multiblock read count=8; 
SQL> select * from alex t401 where object id<=10000; 
Elapsed: 00: 00: 24.35 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
[ 0 | SELECT STATEMENT | 1 1965 | 195K| 260 (1)1 
I* 1 | TABLE ACCESS FULL| ALEX T401 | 1965 | 195K| 260 (1)1 
Statistics 


22 db block gets 
1549 consistent gets 
938 physical reads 
5 sorts (memory) 

0 sorts (disk) 
9014 rows processed 


当 修 改 该 参数 为 一 个 比较 大 的 值 的 时 候 ， 同 样 的 操作 ， 其 COST 开 销 明 显 小 了 很 多 ,执行 时 间 也 短 了 。 可 以 看 到 该 参数 会 直接 影响 到 CBO 优 化 器 的 成 本 计算 ， 是 不 得 不 重视 起 来 的 一 个 参数 。 


SQL> alter session set db file multiblock read count=128; 
SQL> select * from alex t401 where object id<=10000; 
Elapsed: 00: 00: 22.75 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 1965 | 195K| 167 (2) | 
Il* 1 | TABLE ACCESS FULL| ALEX T401 | 1965 | 195K| 167 (2)1 
Statistics 


0 db block gets 
1520 consistent gets 
923 physical reads 

0 sorts (memory) 

0 sorts (disk) 
9014 rows processed 


顺便 提 一 下 ， 在 EXP/IMP 叶 数 的 时 候 ， 将 该 参数 设置 得 大 一 些 ， 可 以 提高 导数 的 效率 ， 但 是 对 直接 路 径 导 数 的 优化 效果 不 是 很 理想 。 


3.OPTIMIZER_FEATURES_ENABLE 


该 参数 控制 着 一 组 优化 器 参数 ， 其 中 大 多 是 隐藏 参数 ， 我 们 可 以 独立 设置 这 些 参数 ， 这 些 隐藏 参数 通常 可 启用 或 禁用 特定 的 优化 器 功能 。 但 是 不 到 万 不 得 已 ， 不 要 去 设置 ， 隐 藏 参数 的 修改 往往 会 带 来 
很 多 不 可 预期 的 影响 。 通 常情 况 下 ， 只 需要 进行 OPTIMIZER_FEATURES_ENABLE 参 数 设置 即 可 。 


然而 ， 这 里 需要 注意 的 是 该 参数 的 向 下 兼容 问题 。 假 设 我 们 做 了 一 次 Oracle 数 据 的 升级 工作 ， 原 始 版 本 是 10.2.0.3， 升 级 后 的 版 本 为 10.2.0.5。 在 原始 版 本 中 ，OPTIMIZER_FEATURES_ENABLE 设 置 的 
值 为 “10.2.0.3”， 那 么 如 果 想 要 保持 CBO 优 化 器 的 稳定 性 ， 则 需要 将 该 参数 在 升级 后 的 版 本 中 也 设置 为 “10.2.0.3”。 


4.0PTIMIZER INDEX CACHING 


OPTIMIZER_INDEX_CACHING 参 数 与 说 套 循环 配合 使 用 ， 用 于 控制 索引 探测 的 成 本 ， 其 值 的 范围 在 0 到 100 之 间 ， 表 示 在 高 速 缓存 中 索引 块 占 的 百分比 。 该 参数 仅 作 用 于 嵌 套 循环 和 IN 列 表 的 遍历 ， 而 
对 索引 最 常用 到 的 范围 扫描 基本 上 没有 什么 影响 。 换 而 言 之 ， 该 参数 设置 为 默认 即 可 。 


5.OPTIMIZER_INDEX_COST_ADJ 


OPTIMIZER_INDEX_COST_ADJ 参 数 也 是 用 来 控制 索引 探测 的 成 本 ， 其 值 的 范围 在 1 和 10000 之 间 ， 默 认 值 为 100， 视 为 索引 正常 成 本 模型 的 一 个 访问 路 径 。 如 果 设 置 为 10 表 示 索 引 访 问 路 径 的 成 本 是 正 
常 成 本 的 十 分 之 一 ， 此 参数 的 设置 会 直接 影响 CBO 优 化 器 是 否 考虑 走 索引 扫描 。 也 就 是 说， 与 OPTIMIZER_INDEX_CACHING 不 同 ，OPTIMIZER_INDEX_COST_ADJ 是 会 影响 到 索引 聚 篮 因 子 的 判断 的 。 


从 下 面 的 例子 可 以 看 到 ， 该 参数 设置 得 太 高 ， 索 引 扫 描 的 成 本 也 会 被 视 为 很 高 ， 往 往 导致 CBO 优 化 器 拒绝 走 索引 扫描 。 因 此 ， 在 高 效 索 引 设计 与 维护 的 前 提 下 ， 应 尽 可 能 地 将 该 参数 的 值 设置 得 低 一 
些 ， 使 优化 器 更 趋向 于 走 索引 。 


SQL> alter session set optimizer index _ cost adj=100; 
SQL> select * from alex t401 where object id<=10000; 


| Id | Operation | Name | Rows | Byte s | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 965 | 195K | 74 (0) | 
| 1 1 TABLE ACCESS BY INDEX ROWID| ALEX T401 | 1965 | 195K | 74 (0) | 
| 二 全 INDEX RANGE SCAN | IDX ALEX T401 ID| 1965 | | 6 (0) | 


SQL> alter session set optimizer index cost adj=1000; 
SQL> select * from alex t401 where object id<=10000; 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| 
| 0 | SELECT STATEMENT | | 1965 | 195K| 167 (2) | 
Il* 1 | TABLE ACCESS FULL| ALEX T401 | 1965 | 195K| 167 (2)1 


然而 ,设置 该 参数 不 是 一 个 很 好 的 常规 优化 手段 ， 不 可 以 轻易 修改 。 对 于 升级 后 的 数据 库 ， 应 该 保持 其 值 与 升级 前 一 致 。 


6.PGA AGGREGATE TARGET 


从 Oracle 9i 开 始 ，Oracle 推 荐 使 用 自动 PGA 内 存 管理 ， 只 需要 设置 该 参数 为 合适 的 大 小 即 可 。 总 体 来 说 ， 与 自动 SGA 管 理 不 同 ，Oracle 自 动 管理 PGA 还 是 不 错 的 ， 推 荐 自动 管理 ， 降 低 运 维 成 本 。 该 参 
数 看 似 与 CBO 优 化 器 没有 太 直 接 的 关系 ， 但 它 是 直接 面 对 用 户 会 话 行为 的 内 存 区 域 ， 把 问题 能 在 前 端 解决 永远 是 最 好 的 选择 。 


风 
的 


很 遗憾 的 是 ， 我 们 没有 办 法 给 出 一 个 合理 的 PGA_AGGREGATE_TARGET 参 数 的 值 ， 因 为 它 是 依赖 于 前 端 会 话 的 并 发 度 的 ， 对 于 一 个 高 并 发 的 数据 库 来 说 ， 可 以 考虑 设置 一 个 较 大 的 PGA 内 存 


7.CURSOR SHARING 


此 参数 将 SQL 语句 中 的 “变量 ” 值 转换 成 绑 定 变量 。 这 个 带 引号 的 变量 ， 表 明 的 是 这 个 变量 是 Oracle 认 为 是 变量 的 文本 。 该 参数 通常 是 用 于 强制 绑 定 变量 的 设置 。 大 多 数 情况 下 ， 绑 定 变量 的 问题 我 们 
都 是 可 控 的 ， 只 有 对 于 一 些 外 购 系统 ，SQL 是 写 死 的 ，DBA 将 无 从 优化 ， 这 个 时 候 就 需要 设置 为 强制 绑 定 变量 ， 来 干预 CBO 优 化 器 的 行为 。 必 须 注意 的 是 ， 将 该 参数 设置 为 “Force” 来 强制 绑 定 变量 会 导 
致 不 少 的 Bug， 建 议 仅 设置 会 话 级 的 强制 操作 ， 控 制 风险 。 


综 上 所 述 ， 对 于 与 CBO 优 化 器 相关 的 初始 化 参数 ， 能 保持 默认 值 的 ， 尽 量 保持 默认 值 ， 反 之 ， 也 需要 考虑 数据 库 具 体 的 应 用 ， 参 考 历史 经 验 值 进行 设置 。 


4.2 像 优 化 器 一 样 思考 


充分 了 解 并 完美 使 用 CBO 优 化 器 ， 就 需要 做 到 像 优化 器 一 样 去 思考 ， 了 解 其 最 核心 的 成 本 计算 机 制 。 下 面 我 们 就 给 大 家 具体 展开 介绍 。 


4.2.1 成 本 计算 机 制 


现在 ， 我 们 知道 了 CBO 是 一 种 基于 成 本 计算 的 优化 器 ， 它 将 SQL 语句 执行 过 程 中 的 每 一 个 动作 都 进行 成 本 的 量化 ， 并 反映 到 执行 计划 中 。 成 本 计算 过 程 中 ， 简 单 的 基本 原则 是 : 
“ 将 单 块 读 成 本 作为 单位 成 本 ; 


“ 量化 所 有 操作 的 成 本 ， 并 转换 为 单位 成 本 。 


在 一 些 Oracle 的 官方 文档 上 面 ， 我 们 能 找到 Oracle 给 出 的 一 个 COST 计 算 公 式 如 下 : 


#SRDS * SREADTIM 十 #MRDS * MREADTIM 十 #CPUCYCLES /CPUSPEED 
SREADTIM 


COST = 


公式 中 因子 的 解释 如 下 : 


“ #SRDS: 单数 据 块 读 的 次 数 


“ #MRDS: 多 数据 块 读 的 次 数 


: SREADTIM: 平均 单 块 读 取 的 时 间 


* MREADTIM: 平均 多 块 读 取 的 时 间 


“ #CPUCYCLES: CPU 指令 数 
* CPUSPEED: CPU 速度 


我 们 知道 优化 器 计算 的 COST 是 MO COST 与 CPU COST 之 和 ， 以 上 公式 的 分 子 部 分 中 ， 多 块 读 与 单 块 读 之 和 为 MO COST，#CPUCYCLES/CPUSPEED 为 CPU COST， 整 体 成 本 对 比 单 块 读 的 时 间 (分 
母 ) ， 换 算 成 单 块 读 的 次 数 ， 即 单位 成 本 。 


不 得 不 提 的 是 ， 根 据 系统 统计 信息 的 收集 模式 不 同 ，CBO 优 化 器 进行 成 本 计算 的 机 制 也 是 不 一 样 的 。 系 统统 计 信息 收集 的 模式 分 为 非 工作 量 (UNWORKLOAD) 模式 和 工作 量 (WORKLOAD) 模式 两 
种 ， 下 一 节 中 将 展开 介绍 。 这 里 只 介绍 不 同 模式 对 成 本 计算 的 影响 ， 工 作 量 模式 的 成 本 计算 中 ， 系 统 会 给 出 一 些 因子 的 数值 ， 而 非 工作 量 模式 下 ， 相 关 因 子 都 是 需要 计算 得 到 的 。 


下 面 我 们 将 分 析 两 种 模式 下 ， 全 表 扫 描 和 索引 扫描 两 种 最 常用 的 成 本 计算 方法 。 


1. 非 工作 量 模式 成 本 计算 


有 了 以 上 的 通用 公式 ， 我 们 还 是 有 一 种 很 无 助 的 感觉 ， 这 些 因子 的 数值 去 哪里 获取 呢 ? Jonathan LewisI1] 大 师 给 了 我 们 指引 : 


#SRDS = LVLS + #LB*ix sel+ ix sel with filters*CLUF 
#MRDS = #BIks/MBRC 
SREADTIM = IOSEEKTIM + db_block_size/IOTFRSPEED 


MREADTIM = IOSEEKTIM + MBRC *db_block_ size/IOTFRSPEED 


其 中 各 个 因子 注释 如 下 : 

“LVLS: 索引 高 度 ; 

“#LB: 索引 叶 节点 的 块 数 ; 

“ix_sel: 索引 的 选择 度 ; 

“ix_sel_with_filters: 表 选 择 度 ; 

: CLUF: 索引 列 的 聚 答 因子 ; 

“#Blks: 表 (HWM 以 下 ) 所 包含 的 数据 块 数 ; 

: MBRC: 一 次 多 块 读 所 读 取 的 数据 块 数 ， 参 照 db_fle_multiblock_read_count 的 值 ; 
“db_block_size: 数据 库 的 数据 块 大 小 ; 

"I/OSEEKTIM: I/O 寻 址 时 间 (默认 值 : 10ms) ; 


“I/OTFRSPEED: I/O 传 输 速 度 (默认 值 : 4096 byte/ms) 。 


太 棒 了 ! 现在 我 们 有 了 这 些 因 子 ， 可 以 转换 得 到 我 们 需要 的 公式 了 。 


对 于 全 表 扫 描 来 说 ，Oradle 是 进行 多 块 读 的 ， 其 单 块 读 发 生 的 次 数 为 0， 即 : #SRDS = 0， 则 公式 可 以 演化 为 : 
#MRDS * MREADTIM 十 #CPUCYCLES /CPUSPEED 
SREADTIM 


COST = 


再 将 以 上 各 项 因子 代入 ， 可 以 得 到 最 终 的 公式 : 


#Blks db_block size | 
MBRC* IOSEEKTIM 十 MBRC * IOTERSPEED 十 #CPUCYCLES/ CPUSPEED 
COST = 
db block size 


IOTFRSPEED 


IOSEEKTIM 十 


对 于 索引 扫描 来 说 ，Oracle 进 行 的 是 单 块 读 操 作 ， 其 多 块 读 次 数 为 0%， 即 : #MRDS = 0， 则 公式 可 以 演化 为 : 


#SRDS * MREADTIM 十 #CPUCYCLES / CPUSPEED 
SREADTIM 


COST = 


同样 代入 因子 后 ， 可 得 到 最 终 公 式 如 下 : 


COST = 

. i ee db block size\  #CPUCYCLES 
(LVLST#LB*1x sel)T(x sel with filters* CLUF))*|IOSEEKTIM 十 一 一 一 | 十 一 一 一 一 一 一 
的 IOTFRSPEED CPUSPEED 
db block size 
IOTFRSPEED 


以 上 公式 看 上 去 非常 复杂 ， 除 了 可 以 分 拆 CPU COST 和 I/O COST 来 看 ， 还 可 以 进一步 分 拆 //O COST 为 索引 扫描 MO COST 和 表 扫描 MO COST， 即 对 应 分 子 中 的 (LVLS + #LB 


IOSEEKTIIM 十 


*ix_sel) ”和 ”(ix_sel with_filters*CLUF) ” ， 当 然 也 可 以 分 开 建 立 公式 ， 便 于 阅读 。 


2. 工 作 量 模式 成 本 计算 


该 模式 下 ， 我 们 可 以 通过 以 下 语句 从 数据 字典 中 直接 获取 相关 因子 的 数值 : 


SQL> select pname, pvall from sys.aux stats$ 
2 where sname="'SYSSTATS MAIN'; 


PNAME, PVAL]1 
CPUSPEEDNW 1137.211 
IOSEEKTIM 13.123 
IOTFRSPEED 35299.813 
SREADTIM 3.764 
MREADTIM 8:915 
CPUSPEED 1110 
MBRC 15 
MAXTHR 5120 
SLAVETHR 


想 。 


这 样 ， 上 述 全 表 扫描 的 公式 可 以 简化 为 : 
#Blks 


MBRC 
COST = 


* MREADTIM + #CPUCYCLES /CPUSPEED 


SREADTIM 


索引 扫描 的 公式 可 以 简化 为 : 
COST = 
SREADTIM 


说 到 这 里 ， 相 信 很 多 人 已 经 有 些 头 晕 了 ， 这 么 多 复杂 的 公式 ， 全 都 是 一 些 抽象 的 概念 ， 真 的 有 意义 吗 ” 我 们 不 是 一 直 在 说 大 道 至 简 吗 ” 和 高 并 发 有 关联 吗 ” 没 错 ， 大 道 至 简 ! 这 是 我 们 的 设计 指导 思 
但 是 不 深入 了 解 一 下 CBO 优 化 器 的 成 本 计算 机 制 ， 我 们 就 无 法 像 优 化 器 一 样 去 思考 ， 那 么 CBO 只 能 是 个 “黑匣子 ”， 这 么 核心 的 内 容 如 果 出 现 盲点， 又 谈 何 优化 高 并 发 呢 ? 


如 果 说 ， 我 们 的 目标 是 一 位 架构 师 ， 那 么 这 些 内 容 是 不 可 能 回避 的 。 下 面 我 们 通过 一 些 实例 来 推导 一 下 这 些 公 式 吧 ， 这 样 理解 起 来 会 方便 许多 。 


4.2.2 成 本 计算 公式 推导 


息 、 


1.10053 事 件 跟踪 工具 


成 本 计算 公式 的 推导 ， 这 里 我 们 需要 借助 一 下 Oracle 内 部 的 10053 事 件 跟踪 工具 ， 该 事件 可 以 用 于 DUMP 出 优化 器 解析 SQL 语 句 的 过 程 ， 包 括 : SQL 语句 及 执行 计划 、 数 据 库 相 关 初始 化 参数 、 系 统 信 
成 本 计算 各 项 因子 等 。 


(1) 10053 事 件 跟踪 工具 可 以 通过 以 下 SQL 语 句 开启 与 关闭 ， 其 级 别 分 为 1 和 2 两 个 等 级 。 与 10046 事 件 跟踪 工具 不 同 ，10053 事 件 跟 踪 工 具 的 等 级 1 包含 更 多 的 信息 。 


.Level 1: 统计 信息 和 推算 信息 。 


(2) 开启 10053 事 件 跟踪 工具 : 


SQL> alter session set events '10053 trace name Context forever, 
2 level [1,2]'; 


(3) 关闭 10053 事 件 跟踪 工具 : 


SQL> alter session set events '10053 trace name context off'; 


在 正式 开始 推导 之 前 ， 我 们 还 需要 了 解 两 个 直接 影响 成 本 计算 结果 的 隐藏 参数 : 


._OPTIMIZER_CEIL COST: 当 其 值 设置 为 “TRUE”，CBO 优 化 器 的 成 本 计算 值 需 要 加 上 ceil 了 水 数 修正 结果 。 
" _TABLE_SCAN_COST_PLUS_ONE: 当 其 值 设 置 为 “TRUE”，CBO 优 化 器 在 估算 全 表 扫 描 和 索引 快速 全 扫描 的 时 候 ， 成 本 结果 值 需要 加 1 修正 。 


“ 在 下 述 的 推导 过 程 中 ， 以 上 两 个 参数 均 设置 为 “TRUE” ， 成 本 计算 结果 需要 修正 。 


2. 非 工作 量 模式 推导 


下 面 先 来 进行 非 工作 量 模式 下 的 公式 推导 吧 ， 对 表 alex_t401 进 行 一 次 简单 的 object id 索引 列 的 等 值 查询 ， 如 下 所 示 ， 没 有 意外 ， 索 引 扫描 更 优 。 


SQL> alter session set events '10053 trace name Context forever, 
2 level 1'; 

SQL> select * from alex t401 where object id=1002; 

SQL> alter session set events '10053 trace name context off' 


ee 交 汪 5 于 
| Id | Operation | Name | Rows | Bytes | Cost | 
De tt RE CLA EO SR DN i 
| 0 | SELECT STATEMENT | | | | >| 
| 1 | TABLE ACCESS BY INDEX ROWID | ALEX T401 1 二 102 | 2 1 
| 村 | INDEX RANGE SCAN | IDX ALEX T401 ID | | ' 让" 
De ea el 


日 志文 件 包括 : 系统 统计 信息 区 域 、 对 象 基本 统计 信息 区 域 、 各 种 执行 计划 成 本 估算 区 域 。 摘 取 一 下 10053 事 件 跟 踪 的 日 志文 件 来 具体 分 析 一 下 。 


一 -系统 统计 信息 区 域 


因 详 次 突 闪 关 奖 大奖 次 六 六 六 次 六 大 闪光 闪 太太 次 六 大 突 类 六 六 


SYSTEM STATISTICS INFORMATION 
六 闪 关 闪光 六 六 大 次 六 交大 六 交大 六 次 六 类 大 六 大 六 六 交大 大奖 
Using NOWORKLOAD Stats 
CPUSPEED: 1103 millions instruction/sec 
IOTFRSPEED: 4096 bytes per millisecond (default is 4096) 
IOSEEKTIM: 10 milliseconds (default is 10) 
一 -对 象 基本 统计 信息 区 域 


尖 六 类 闪 六 大庆 类 六 大 闪 类 六 六 关头 六 类 闪 尖 六 大 六 类 交火 闪 因 六 大 大 次 六 六 六 因 六 大 


BASE STATISTICAL INFORMATION 
兴 次 六 大 大 六 交大 六 次 六 六 大 次 类 类 六 六 次 太太 次 
Table Stats:: 
Table: ALEX T401 Alias: ALEX T401 
#Rows: 61551 #Blks: 947 AvgRowLen: 102.00 
Index Stats:: 
Index: IDX ALEX T401 ID Col#: 4 
LVLS: 1 #LB: 137 #DK: 61546 LB/K: 1.00 DB/K: 1.00 CLUF: 2126.00 
一 -各 种 执行 计划 成 本 估算 区 域 
兴 次 六 炎炎 六 次 关 六 次 大 六 闪 次 六 次 闫 六 交大 大 次 大 六 次 关 类 类 六 六 次 六 六 次 六 六 大 因 
SINGLE TABLE ACCESS PATH 
Access Path: TableScan 
Cost: 210.72 Resp: 210.72 Degree: 0 
Cost_ io: 209.00 Cost cpu: 22740322 
Resp io: 209.00 Resp cpu: 22740322 
Access Path: index (AllEgqRange) 
Index: IDX ALEX T401 ID 
resc io: 2.00 resc cpu: 15683 
ix sel: 1.6248e-05 ix sel with filters: 1.6248e-05 
Cost: 2.00 Resp: 2.00 Degree: 1 
Best:: AccessPath: IndexRange Index: IDX ALFEX T401 ID 
Cost: 2.00 Degree: 1 Resp: 2.00 Card: 1.00 Bytes: 0 


分 析 步 骤 如 下 : 


步骤 1 先 计算 出 三 个 通用 因子 的 结果 : 


SREADTIM IOSEEKTIM + db block size / IOTFRSPEED 

10+8192/4096 

12 

IOSEEKTIM +db file multiblock read count* db block size / IOTFRSPEED 
10+16*8192/4056 加 加 加 

= 42 

#MRDS = #Blks/MBRC = 947/16 


MREADTIM 


步骤 2 计算 全 表 扫 描 成 本 : 


I/O COST = 1 + ceil (#MRds * MREADTIM / SREADTIM)) 
1 + ceil (947/16*42/12) 

209 

#CPUCYCLES/CPUSPEED/1000/SREADTIM 
Cost_ cpu/CPUSPERED/1000/SREADTIM 
22740322/1103/1000/12 

1.72 

COST + CPU COST 

:72 


CPU COST 


COST 


O 
0 


9 HH 
已 全 


至 此 ， 我 们 计算 出 如 果 查 询 走 全 表 扫 描 的 方式 ， 其 成 本 为 210.72， 与 CBO 优 化 器 计算 出 来 的 结果 不 谋 而 合 ， 也 验证 了 公式 的 正确 性 。 细 心 的 读者 应 该 发 现 了 ， 我 们 在 进行 CPU 成 本 计算 的 时 候 ， 做 了 一 
次 单位 的 换算 ，CPUSPEED 单 位 从 毫秒 转换 成 秒 。 


步骤 3 计算 索引 扫描 成 本 : 


Index I/O COST LVLS + ceil(#LB * ix sel) 


1+ceil (137*0.000016248) 
1 


Table I/O COST Ceil (CLUF * ix sel with filters) 


ceil (2126*0.000016248) 


二 
I/O COST + Table I/O COST 


I/O COST = Index 
2 
CPU COST #CPUCYCLES/CPUSPEED/1000/SREADTIM 
resc_ cpu/CPUSPEED/1000/SREADTIM 
15683/1103/1000/12 
=0 
COST I/O Cost + CPU Cost 


这 个 结果 和 CBO 优 化 器 的 计算 结果 也 是 一 致 的 。 优 化 器 通过 两 种 方式 对 比 ， 最 终 选 择 成 本 更 低 的 索引 扫描 为 最 优 路 径 ， 并 按照 该 路 径 生成 最 终 的 执行 计划 。 


3. 工 作 量 模式 推导 


工作 量 模式 下 的 推导 与 非 工作 量 模式 下 是 大 同 小 异 的 。 


步骤 1 ” 先 查 询 出 四 个 通用 因子 的 结果 值 : 


SQL> select pname, pvall from sys.aux stats$ 
2 where sname="'SYSSTATS MAIN'; 
PNAME. PVAL]1 


SREADTIM 3.764 


MREADTIM 8.915 
CPUSPEED 1110 


MBRC 15 


再 分 析 10053 事 件 跟踪 日 志文 件 ， 计 算 成 本 : 


一 -系统 统计 信息 区 域 
兴 次 六 关 关 六 次 关 六 次 大 六 大 次 六 大 六 六 交大 六 次 六 六 奖 罗 六 大 
SYSTEM STATISTICS INFORMATION 
六 闪光 炎炎 大 六 次 关 六 次 次 六 次 次 六 大 大 六 交大 六 次 六 类 大 罗 六 大 
Using WORKLOAD Stats 
CPUSPEED: 1110 millions instructions/sec 
SREADTIM: 4 milliseconds 
MREADTIM: 9 millisecons 
MBRC: 15.000000 blocks 
MAXTHR: 5120 bytes/sec 
SLAVETHR: -1 bytes/sec 
一 -对 象 基本 统计 信息 区 域 
六 闪 关 闪光 六 六 碳 交 六 次 闫 六 交火 大 次 六 六 闪 关 六 交大 光大 大 次 六 六 并 关 六 交大 光 大 
BASE STATISTICAL INFORMATION 
兴 关 六 六 大 六 交大 六 次 交大 交 六 六 六 六 交大 大 兴 
Table Stats::; 
Table: ALEX T401 Alias: ALEX T401 
#Rows: 61551 #Blks: 947 AvgRowLen: 102.00 
Index Stats:: 
Index: IDX ALEX T401 ID Col#: 4 
LVLS: 1 #LB: 137 #DK: 61546 LB/K: 1.00 DB/K: 1.00 CLUF: 2126.00 
一 -各 种 执行 计划 成 本 估算 区 域 
兴 次 六 次 次 六 次 关 闪光 次 六 并 次 六 六 并 六 次 大 大 次 奖 六 次 交 六 六 奖 六 交大 大 次 交 因 闪 交 
SINGLE TABLE ACCESS PATH 
Access Path: TableScan 
Cost: 156.44 Resp: 156.44 Degree: 0 
Cost io: 151.00 Cost cpu: 22740322 
Resp io: 151.00 Resp cpu: 22740322 
Access Path: index (AllEgqRange) 
Index: IDX ALEX T401 ID 
resc io: 2.00 resc cpu: 15683 
ix sel: 1.6248e-05 ix sel with filters: 1.6248e-05 
Cost: 2.00 Resp: 2.00 Degree: 1 
Best:: AccessPath: IndexRange Index: IDX ALEX T401 ID 
Cost: 2.00 Degree: 1 Resp: 2.00 Card: 1.00 Bytes: 0 


步骤 2 计算 全 表 扫 描 成 本 : 


#MRDS = #Blks/MBRC = 947/15 

I/O COST = 1 + ceil (#MRds * MREADTIM / SREADTIM)) 
1 + ceil(947/15*8.915/3.764) 

151 


CPU COST = #CPUCYCLES/CPUSPEED/1000/SREADTIM 
= Cost cpu/CPUSPEED/1000/SREADTIM 
= 22740322/1110/1000/3.764 
= 5.44 
COST = I/O COST + CPU COST 
= 156.44 


此 时 计算 出 查询 走 全 表 扫 描 的 方式 的 成 本 为 156.44， 与 CBO 优 化 器 计算 出 来 的 结果 也 是 一 致 的 ， 进 一 步 验证 了 公式 的 正确 性 。 


步骤 3 计算 索引 扫描 成 本 : 


#MRDS = #Blks/MBRC = 947/15 

Index I/O COST = LVLS + ceil(#LB * ix sel) 
1l+ceil (137*0.000016248) 

1 

Table I/O COST Ceil (CLUF * ix sel with filters) 
ceil (2126*0.000016248) 


1 
I/O COST = I/O COST + Table I/O COST 


1 
四 
如 
Ko 
x 


2 
#CPUCYCLES/CPUSPEED/1000/SREADTIM 
resc cpu/CPUSPEED/1000/SREADTIM 
15683/1110/1000/3.764 

0 


CPU COST 


COST = I/O Cost + CPU Cost 
这 


通过 以 上 公式 的 计算 和 推导 ， 主 要 是 希望 给 各 位 读者 传递 一 个 思考 问题 的 方式 : 像 CBO 优 化 器 一 样 去 思考 问题 ， 这 样 很 多 问题 就 不 再 是 问题 了 。 我 们 不 建议 纠结 在 复杂 的 算法 和 推演 过 程 中 ， 因 为 我 们 
不 是 要 做 学 术 研 究 ， 而 是 要 更 好 地 理解 和 使 用 Oracle， 我 们 是 使 用 者 ， 不 是 研发 者 。 


[1] 《Cost Based Oracle Fundamentals》 一 书 作 者 。 


4.3 ”统计 信息 管理 


我 们 已 经 了 解 了 CBO 优 化 器 的 工作 原理 ， 成 本 计算 的 准确 性 直接 决定 了 执行 计划 生成 的 优 和 学 ， 进 而 影响 到 SQL 语 句 执行 效率 的 高 低 ， 这 个 过 程 中 的 关键 点 就 是 成 本 计算 的 准确 性 。 通 常情 况 下 ，CBO 优 
化 器 的 算法 基本 上 是 不 变 的 ， 而 直接 影响 CBO 计 算 的 因素 就 成 了 统计 信息 ， 换 而 言 之 ， 统 计 信 息 的 准确 性 决定 了 成 本 计算 的 准确 性 。 


对 于 一 套 比 较 空 闲 的 数据 库 系 统 来 说 ， 我 们 甚至 可 以 不 关心 CBO 优 化 器 和 统计 信息 的 行为 ， 因 为 我 们 对 性 能 和 并 发 没有 要 求 。 但 是 ,我 们 面 对 的 是 一 套 高 并 发 压力 较 大 的 系统 的 话 ， 特 别 是 执行 的 SQL 
语句 不 算 太 简单 的 应 用 ， 那 我 们 不 得 不 细 化 统计 信息 管理 的 工作 。 


如 图 4-2 所 示 ， 如 果 我 们 需要 开车 从 A 点 到 B 点 ， 行 程 非常 简单 ， 那 么 不 论 用 什么 导航 ， 或 者 用 不 用 导航 ， 我 们 都 将 直线 行程 ， 这 就 好 比 CBO 优 化 器 给 一 句 很 简单 的 SQL 语句 生成 执行 计划 ， 此 时 的 “路 
况 信息 ”可 以 适当 地 忽略 。 如 果 是 需要 从 A 点 到 C 点 ， 情 况 就 不 一 样 了 ， 看 似 虚 线 的 路 况 不 错 ， 但 是 导航 却 让 我 们 走 实 线路 径 ， 因 为 导航 判断 了 沿路 的 “拥堵 ”情况 ， 就 像 CBO 优 化 器 给 一 条 较 复杂 的 SQL 语 
句 生成 的 执行 计划 ， 路 径 变数 很 多 ， 我 们 需要 依赖 准确 的 “路 况 信息 ” (统计 信息 ) 。 


4-2 CBO 优化 器 导航 线路 图 


准确 的 统计 信息 能 引领 CBO 优 化 器 生成 较 优 的 执行 计划 ， 获 得 SQL 语 句 高 效 执行 。 然 而 ， 我 们 同时 不 能 忽视 的 是 ， 如 果 统 计 信息 收集 得 不 准确 ， 即 使 从 A 点 到 B 点 ， 也 可 能 带 着 CBO 优 化 器 在 不 断 地 “ 绕 
路 ”。 打 个 比方 来 说 : RBO 优 化 器 就 像 一 张 纸 质地 图 ， 一 是 一 二 是 二 ; 而 CBO 优 化 器 是 一 台 高 效 的 行程 导航 ， 但 必须 及 时 更 新 电子 地 图 和 实时 路 况 信息 ， 否 则 它 可 能 带 你 去 “撞墙 ”。 


统计 信息 的 作用 就 像 一 把 双 丸 剑 ， 我 们 可 以 不 用 太 多 太 深 地 了 解 CBO 优 化 器 的 原理 ， 但 是 统计 信息 的 管理 却 不 容 忽 视 。 


4.3.1 ”统计 信息 分 类 


在 Oracle 数 据 库 中 ， 统 计 信息 分 为 系统 统计 信息 和 对 象 统计 信息 ， 并 在 Oracle 9i 之 后 提供 了 一 个 系统 工具 包 DBMS_STATS 用 于 统计 信息 的 管理 。 其 功能 包括 : 


“ 统计 信息 的 收集 ， 并 存储 到 数据 字典 中 ; 


“ 备份 及 还 原 统 计 信 息 ; 


“ 锁定 及 解锁 统计 信息 ; 


“ 统计 信息 的 导入 与 导出 。 


1. 系 统统 计 信息 


系统 统计 信息 在 上 一 节 已 经 提 及 ， 它 包括 MO 性 能 和 利 


情况 、CPU 性 能 和 利 | 


情况 ， 主 要 作用 于 CBO 优 化 器 的 算法 干预 。 在 9i 之 前 ，CBO 优 化 器 更 侧重 于 MO 成 本 的 计算 ， 在 9i 之 后 ， 则 更 关注 于 CPU 


速度 对 成 本 计算 的 影响 ， 系 统统 计 信息 的 存在 就 是 帮忙 CBO 优 化 器 合理 平衡 CPU 成 本 和 IO 成 本 的 计算 ， 使 其 更 为 准确 。 


系统 统计 信息 有 两 种 收集 模式 : 非 工 作 量 (NOWORKLOAD) 模式 、 工 作 量 


(1) 非 工作 量 模式 统计 信息 


WORKLOAD) 模式 ， 其 对 CBO 优 化 器 的 影响 上 一 节 已 经 介绍 过 了 。 


Oracle 在 默认 情况 下 ， 是 进行 非 工作 量 模式 下 的 系统 统计 信息 收集 的 ， 这 个 过 程 是 可 以 自动 完成 的 ， 可 以 不 需要 人 工 干预 。 当 然 ， 也 可 以 手工 收集 ， 如 下 : 


dbms_stats.gather system stats (gathering mode => "noworkload')7 


该 收集 过 程 非常 快 ， 但 也 需要 在 比较 空闲 的 时 候 进行 ， 便 于 Oracle 稀 量 CPU 的 速度 和 I/O 性 能 情况 。 


(2) 工作 量 模式 统计 信息 


工作 量 模式 下 的 系统 统计 信息 ， 其 实 就 是 基于 两 个 时 间 点 的 快照 的 形式 获取 ， 可 以 手工 抓 取 ， 也 可 以 自动 抓 取 。 


:手工 抓 取 : 抓 取 一 个 开始 快照 ， 经 过 一 段 时 间 工作 量 的 统计 后 ， 再 抓 取 一 个 结束 快照 ， 即 可 完成 收集 过 程 。 


dbms_stats.gather_system_stats (gathering mode => 'start'); 
dbms_stats.gather system stats (gathering mode => 'stop'); 


“ 自动 抓 取 : 设置 周期 性 抓 取 ， 并 设置 好 抓 取 频 率 〈 下 例 表示 频率 为 60 分 钟 一 次 ) 即 可 。 


dbms_stats.gather_system_stats (gathering mode => 'interval', 


interval => 60) 


间 ， 


在 AUX_STATS$ 表 中 ， 查 询 SYSSTATS_INFO 的 信息 ， 可 以 监控 收集 过 程 状态 。 如 果 收 集 工作 正常 完成 了 ，STATUS 为 “COMPLETED”， 并 在 DSTART 和 DSTOP 记 录 该 收集 周期 的 开始 时 间 和 结束 时 


FLAGS 则 表示 当前 进度 状态 ， 


“0” 表 示 进 行 中 ，“1” 表 示 准 备 中 。 如 下 所 示 : 


SQL> select pname, pvall, pval2 from sys.aux stats$ 


2 where sname='SYSSTRT: 
PNAME. PVAL1 PVAL2 
STATUS COMPI 
DSTART 03-12 
DSTOP 03-12 
FLAGS 1 


S_INFO'; 


ETED 
-2014 14:00 
-2014 14:00 


非 工作 量 模式 下 收集 ， 开 始 和 结束 时 间 是 一 致 的 ， 收 集 过 程 中 STATUS 和 FLAGS 是 不 会 变化 的 。 在 工作 量 模式 下 ， 各 个 字段 则 会 


自动 收集 状态 ， 则 STATUS 为 “AUTOGATHERING” ， 如 果 是 手工 收集 状态 ， 则 STATUS 为 “MANUALGATHERING” 。 


收集 的 结果 可 以 通过 以 下 查询 来 获取 ， 在 非 工作 量 模式 下 只 能 获取 前 三 项 指标 的 值 : 


反映 整个 收集 过 程 的 状态 ， 收 集 过 程 进行 中 FLAGS 显 示 为 “0”， 如 果 是 


SQL> select pname, pvall f 


2 where sname='SYSSTAT: 
PNAME, PVALT 
CPUSPEEDNW 1086.647 
IOSEEKTIM 11.12 
IOTFRSPEED 52301 .215 
SREADTIM 2.619 
MREADTIM 7.619 
CPUSPEED 1087 
MBRC 16 
MAXTHR 
SLAVETHR 


rom sys.aux stats$ 
S MAIN'; 


地 去 


各 项 指标 的 说 明 如 表 4-1 所 示 : 


参 


参数 
CPUSPEEDNW 
IOSEEKTIM 
IOTFRSPEED 
SREADTIM 


MREADTIM 


虽然 说 系统 统计 信息 很 重要 ， 


2. 对 象 统计 信息 


10g 开 始 ， 添 加 了 更 多 对 象 统计 信息 相关 视图 ， 


对 象 统计 信息 ， 顾 名 思 义 就 是 数据 库 对 象 的 


表 4-1 
说 明 
CPU 一 秒 钟 的 处 理 次 数 


IO 寻 址 时 间 (默认 值 : 10ms ) 


LO 传输 速度 (默认 值 : 4096 byte/ms) 


平均 单 块 读 取 的 时 间 
平均 多 块 读 取 的 时 间 


但 是 在 非 必 要 的 情况 下 ， 我 们 还 是 不 要 过 多 地 干预 会 比较 好 ， 就 保持 Oracle 在 非 工作 量 模式 下 的 
F 预 系统 统计 信息 收集 的 。 对 于 系统 统计 信息 ， 做 到 基本 的 了 解 就 好 了 ， 更 多 的 关注 应 该 放 在 对 象 ( 表 和 索引 ) 统计 信息 的 管理 上 。 


1) 表 的 统计 信息 ， 其 包括 : 该 表 有 多 少数 


user tab_statistics 查 询 获取 。 


可 以 更 有 针对 性 地 查看 和 分 析 。 


SQL> select * from user tab _ statisticsy 


系统 统计 信息 参数 说 明 


参 。 数 说 有明 
CPUSPEED CPU 一 秒 钟 的 处 理 次 数 
MBRC 一 次 多 块 读 所 读 取 的 数据 块 数 
MAXTHR LO 最 大 硅 吐 量 

SLAVETHR 并 行 处 理 线 程 的 LO 甜 吐 量 


动 收集 即 可 。 至 少 在 我 接触 到 绝 大 部 分 Oracle 数 据 库 中 ， 都 是 没有 刻意 


统计 信息 ， 包 括 三 种 类 型 的 对 象 统计 信息 : 表 的 统计 信息 、 列 的 统计 信息 、 索 引 的 统计 信息 。 对 于 前 两 种 统计 信息 ， 


很 多 时 候 容易 被 混为一谈 。Oracle 从 


居 块 、 多 少 行 记录 、 平 均 行 长 等 信息 ， 可 以 通过 user tab_statistics 视 图 查询 获取 ，Oracle 也 很 人 性 化 提供 了 该 视图 各 列 的 含义 ， 可 以 通过 desc 


2) 索引 的 统计 信息 ， 其 包括 : 该 索引 有 多 少 叶 节点 数据 块 、 索 引 高 度 、 索 引 条 目 数 等 信息 ， 同 样 的 方式 ， 可 以 查询 user_ind_statistics 视 图 获取 。 


SQL> select * from user ind statistics; 


user tab_histograms 视 图 。 


3) 列 的 统计 信息 ， 需 要 注意 


区 分 一 下 普通 表 和 分 


区 表 ， 并 且 要 关注 一 下 下 列 对 应 的 直方 


信息 。 对 于 普通 表 来 说 ， 列 的 信息 可 以 通过 user tab_col_statistics 视 图 查询 ， 


直方 | 


出 


信息 则 需要 查询 


SQL> select * from user tab col statistics; 
SQL> select * from user tab histograms; 


如 果 是 分 区 表 ， 表 和 索引 的 统计 信息 可 以 像 普通 表 一 样 查询 获取 。 分 


user_subpart_ col statistics 和 user_ subpart_histograms 视 图 。 


区 表 列 的 统计 信息 和 直方 


区 


对 象 统计 信息 的 管理 工作 ， 同 样 也 是 可 以 使 


4.3.2 ”制定 收集 策略 


不 以 规矩 ， 不 成 方圆 。 在 进行 统计 信息 收集 之 前 ， 我 们 应 该 为 这 项 非常 和 
其 效果 可 能 会 更 好 。 我 们 关注 的 恒 


可 以 分 别 查询 user_part_col_statistics 和 user_part_histograms 视 图 ， 


体 使 用 方法 下 面 将 会 


系统 工具 包 DBMS_STATS 来 完成 ， 该 工 


点 应 该 是 表 、 列 和 索引 的 统计 信息 收集 。 


现在 问题 就 集中 在 表 、 列 、 索 引 三 种 对 象 上 了 ， 而 列 是 完全 依赖 于 表 ， 索 引 也 一 定 程度 上 (新 建生 


区 


要 的 工作 制定 一 个 策略 。 对 于 系统 统计 信息 的 收集 策略 ， 在 前 面 我 们 已 经 提 到 了 ， 就 是 让 数据 库 自动 去 收集 ， 不 必 过 多 干 


子 分 区 的 则 需要 查询 


介绍 。 


预 ， 


建 除 外 ) 依赖 于 表 ， 


因此 表 的 统计 信息 当 是 最 核心 的 关注 点 ， 在 收集 表 的 统计 信息 的 同时 是 需要 收 


集 列 和 相关 索引 的 统计 信息 的 。 


值得 提 一 下 的 是 ，Oracle 从 10g 开 始 会 提供 一 个 作业 自动 进行 统计 信息 收集 ， 这 个 功能 是 不 可 取 的 ， 在 数据 库 建 库 初 始 化 的 时 候 就 必须 要 停 掉 ， 否 则 很 有 可 能 会 造成 日 后 的 性 能 问题 。 


我 们 这 里 说 到 的 表 还 需要 细 分 两 种 类 型 : 系统 表 (包括 数据 字典 表 和 固定 对 象 ) 和 业务 表 (包括 普通 表 和 分 区 表 ) 。 


1. 系 统 表 的 统计 信息 收集 


先 来 看 看 数据 字典 表 和 固定 对 象 ， 其 统计 信息 存 不 存在 、 是 否 过 旧 ， 根 本 上 来 说 ， 对 业务 应 用 的 影响 并 不 大 ， 我 遇 到 的 很 多 数据 库 根 本 就 不 理会 这 一 块 的 东西 。 但 是 ， 出 于 严谨 操作 的 考虑 ， 我 们 还 是 
建议 至 少 需要 在 建 库 初 始 化 完成 后 收集 一 次 的 。 


2. 普 通 表 的 统计 信息 收集 


业务 表 是 直接 关系 到 业务 系统 应 用 的 效果 的 ， 所 以 业务 表 的 统计 信息 才 是 关注 的 重 中 之 重 ， 我 们 先 来 看 看 业务 的 普通 表 应 该 如 何 去 制 定 策略 。 


前 面 我 们 说 到 ， 统 计 信 息 就 像 导 航 仪 上 的 最 新 电子 地 图 和 实时 路 况 ， 必 须 保证 这 个 信息 是 没有 过 期 的 ， 这 就 引出 了 统计 信息 收集 的 触发 点 一 一 统计 信息 过 | 日 。 


那么 哪些 行为 会 导致 统计 信息 过 


表 结 构 的 变化 ， 可 以 回顾 一 下 第 3 章 的 内 容 ， 大 致 可 以 分 为 : 


“ 表 的 新 建 初始 化 ， 包 括 : 新 建 表 并 初始 化 数据 ; 


表 的 MOVE 操 作 ; 


“ 表 的 在 线 重 定义 ; 


. 表 的 空间 回收 SHRINK SPACE 操 作 ; 


“ 现 有 表 的 结构 变化 ， 包 括 : 新 增 、 修 改 、 删 减 字段 。 


表 的 数据 的 变化 ， 则 大 致 可 以 分 为 : 


: 截断 表 数 据 (TRUNCATE TABLE) ; 


' 表 上 大 量 数据 的 增 、 删 、 改 操作 (INSERT、UPDATE、DELETE) 。 


日 呢 ? 对 于 一 个 普通 表 来 说 ， 无 外 平 两 种 行为 : DDL 和 DML 操 作 ， 更 准确 地 应 该 说 是 结构 的 变化 和 数据 的 变化 ， 将 会 导致 统计 信息 过 旧 。 


在 第 3 章 我 们 介绍 过 ， 表 的 在 线 重 定义 操作 实质 上 就 是 利用 物化 视图 刷新 功能 新 建 一 个 表 和 所 有 相关 索引 的 过 程 ， 所 以 表 的 在 线 重 定义 的 情况 可 以 视 作 是 表 的 新 建 初始 化 的 情况 。 表 的 空间 回收 操作 实质 
上 就 是 Oracle 内 部 在 不 断 地 DML 操 作 过 程 ， 可 以 将 其 视 为 表 上 大 量 数据 的 增删 改 操作 。 而 TRUNCATE TABLE 操 作 实质 上 是 全 量 删 除 和 空间 回收 ， 也 可 视 为 表 上 的 大 量 数据 增删 改 。 


这 样 表 上 相关 操作 可 以 精简 一 下 了 : 


“ 表 的 新 建 初 始 化 ， 包 括 : 新 建 表 并 初始 化 数据 ; 


表 的 MOVE 操 作 ; 


: 现 有 表 的 结构 变化 ， 包 括 : 新 增 、 修 改 、 删 减 字段 。 


“ 表 上 大 量 数据 的 增删 改 操作 (INSERT、UPDATE、DELETE) 。 


对 于 普通 表 来 说， 以 上 操作 发 生 了 ， 就 应 该 进行 表 、 列 、 相 关 索 引 统计 信息 的 重新 收集 。 如 果 表 上 不 是 经 常会 有 字段 的 增删 改 ， 而 且 表 比较 大 ， 收 集 统计 信息 的 成 本 比较 高 的 情况 下 ， 可 以 考虑 不 本 


收集 。 


3. 分 区 表 的 统计 信息 收集 


新 


判断 分 区 表 统 计 信息 是 否 过 旧 ， 我 们 可 以 参考 普通 表 ， 将 分 区 表 视 为 多 个 普通 表 的 集合 。 对 于 表 数 据 的 变化 ， 分 区 表 和 普通 表 是 一 样 的 ， 关 键 点 是 在 表 结 构 的 变化 。 除 去 与 普通 表 共 同 拥有 的 变化 情 
况 ， 分 区 表 结 构 特 有 的 变化 包括 : 


“分 区 的 新 增 (Add) ; 
“ 分 区 的 拆 分 (Split) ; 


. 分 区 的 合并 (Merge) 


3 


“ 分 区 的 删除 (Drop) 。 


我 们 再 来 分 析 一 下 ， 以 上 操作 都 是 不 会 触发 表 级 的 统计 信息 变化 ， 仅 影响 分 区 的 范围 。 分 区 的 新 增 ， 可 以 视 为 一 次 普通 表 的 新 增 和 数据 初始 化 ; 分 区 的 拆 分， 可 以 视 为 两 个 普通 表 的 新 增 和 数据 初始 


化 ， 如 果 新 分 区 不 包含 数据 


4. 表 的 收集 策略 


这 样 我 们 就 成 功 地 将 分 


， 则 视 为 一 个 普通 表 的 新 建 ， 原 分 区 无 变化 ; 分 区 的 合并 ， 可 以 视 为 一 个 普通 表 的 新 建 和 数据 初始 化 ; 分 区 的 删除 不 必 考 虑 。 


区 表 的 收集 策略 和 普通 表 的 收集 策略 统一 起 来 了 ， 接 下 来 就 需要 给 各 项 操作 来 排 一 个 优先 层级 。 如 图 4-3 所 示 ， 我 们 可 以 大 致 分 为 四 个 


统计 信息 的 收集 是 非常 费时 费 资 源 的 一 项 操作 ， 一 般 都 会 安排 在 非 业 务 高 峰 进行 ， 时 间 窗 口 有 限 ， 所 以 需要 尽 可 能 先 满足 优先 级 较 高 的 。 


层级 ， 从 上 到 下 ， 优 先 级 别 逐 步 降 低 。 


因为 


集 。 


= bz = 下 全 京 三 7 在 分 区 
表 在 线 重 定义 表 的 新 建 初始 化 【| 新 增 、 拆 分 、 合 并 、 删 除 


表 的 MOVE 探 作 


表 的 宇 间 回收 表 大 量 数 据 变化 


表 字 段 变化 


图 4-3 收集 策略 优先 层级 


接 下 来 再 逐一 层级 地 展开 看 一 下 吧 。 


第 一 层级 : 其 根本 就 是 表 的 初始 化 操作 ， 以 及 100% 数 据 变化 量 的 初始 化 操作 ， 无 论 如 何 都 是 需要 进行 收集 的 ， 也 可 以 视 为 统计 信息 的 初始 化 收集 过 程 。 如 果 新 建 的 是 空 表 或 者 空 分 区 ， 则 可 以 暂时 不 收 


第 二 层级 : 表 的 MOVE 操 作 之 所 以 在 第 二 级 ， 因 为 该 操作 同样 意味 着 表 的 重建 和 所 有 相关 索引 的 重建 ， 在 Oracle 10g 之 后 的 版 本 中 ， 该 操作 是 不 会 引起 统计 信息 丢失 的 ， 不 必 重 新 收集 ， 但 是 在 9 各 之 


前 的 版 本 中 ， 是 必须 重新 收集 的 。 


如 下 是 在 Oracle 10g 设 置 的 一 个 例子 : 


SQL> select * from v$version; 

BANNER 

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit 

PL/SQL Release 10.2.0.5.0 - Production 

CORE 10.2.0:5.0 Production 

TNS for HPUX: Version 10.2.0.5.0 - Production 

NLSRTL Version 10.2.0.5.0 - Production 

SQL> select table name, num rows, blocks, avg row len, last analyzed 
from user tab statistics 
3 where table name = 'ALEX T401'; 

TABLE NAME NUM_ROWS BLOCKS AVG ROW LEN LAST ANALYZED 

ALEX T401 61551 946 102 2014-03-11 10:50:55 

SQL> alter table alex t401 move tablespace users; 

Table altered 4 

SQL> select table name, num rows, blocks, avg row len, last analyzed 
2 from user tab statistics 2 
3 where table name = 'ALEX T401'; 


TABLE NAME NUM_ROWS “BLOCKS AVG ROW LEN LAST ANALYZED 
ALEX TA 61551 946 102 2014-03-11 10:50:55 
第 三 层级 : 应 该 是 关注 的 重点 ， 这 个 层级 的 操作 和 第 二 层级 的 操作 不 同 ， 第 二 层级 的 操作 是 不 会 引起 数据 变化 的 ， 这 个 层级 却 是 会 的 。 表 空间 的 回收 也 好 ， 表 的 截断 也 好 ， 关 键 点 是 引起 了 多 少数 据 量 


的 变化 ， 当 数据 量 的 变化 达到 一 定 立 值 就 需要 重新 收集 统计 信息 。 那 么 接 下 来 的 问题 就 集中 在 如 何 去 定 义 这 个 立 值 上 了 。 


我 们 一 直 都 在 说 优秀 的 执行 计划 是 我 们 最 终 的 目标 ， 也 就 是 说 当 数 据 变化 量 达 到 影响 执行 计划 并 使 之 变 差 的 时 候 ， 就 视 为 达到 了 这 个 阅 值 。 一 般 来 说 ,我们 可 以 简单 地 参考 Oracle 自 带 的 收集 任务 的 设 


置 ， 当 发 生 10% 的 数据 量变 化 即 视 为 统计 信息 过 旧 ， 需 要 重新 收集 。 


那么 怎么 判断 是 否 达到 了 这 个 10% 的 阔 值 呢 ? 我 们 需要 借助 user tab_modifications 视 图 来 辅助 计算 。 我 们 通过 一 个 实例 来 看 一 下 吧 。 


步骤 1 表 alex_t401 中 现 有 5 万 行 记录 ， 收 集 好 统计 信息 后 ， 作 为 判断 的 基准 点 。 然 后 ， 再 插入 5 万 行 ， 作 为 数据 的 变化 量 。 


SQL> select count (*) from alex 七 4017 

COUNT (*) 

50000 
SQL> exec dbms_stats.gather table stats('alex','alex t401', 
cascade => true) 

PL/SQL procedure successfully completed 
SQL> insert into alex t401 select * from dba objects 

2 where rownum<=50000; 
50000 rows inserted 
SQL> commit; 
Commit complete 
SQL> select count (*) from alex t401; 

COUNT (*) 


100000 


步骤 2 使 用 DBMS_STATS 包 获取 监控 情况 ， 这 个 监控 周期 是 从 上 次 统计 信息 收集 到 本 次 获取 监控 数据 的 时 间 区 间 。 此 处 ， 不 论 是 INSERT，UPDATE 还 是 DELETE， 都 是 数据 的 变化 ， 对 三 者 求 和 视 为 


数据 变化 的 总 量 ， 然 后 再 对 比 上 次 收集 的 统计 信息 的 NUM_ROWS 的 值 ， 就 是 该 周期 内 表 alex_t401 的 数据 变化 总 量 。 如 果 该 值 超 过 10% 即 视 为 统计 信息 过 | 上 昌 ， 本 例 中 为 100%， 为 严重 过 期 。 


SQL> exec dbms stats.flush database monitoring info 
PL/SQL procedure successfully completed 属 
SQL> select num rows from user tab statistics 

2 where table name="'ALEX T40177 

NUM ROWS 


SQL> select table name, inserts, updates, deletes 
才 from user tab modifications where table name="'ALEX T401'; 


TABLE NAME INSERTS UPDATES DELETES 
ALEX T401 50000 0 0 
SQL> select a.table name, 
2 trunc((a.inserts + a.updates + a.deletes) / 
党 b.num rows * 100, 2) || '%' ratio 
4 from user tab modifications a user tab statistics b 
5 where a.table name = 'ALEX T401' 
6 and a.table name = b.table name; 


TABLE_ NAME RATIO 


ALEX_T401 100% 


值得 注意 的 是 ， 当 重新 对 表 ALEX_T401 收 集 一 次 统计 信息 ， 则 user tab_modifications 视 图 中 对 该 表 的 数据 会 清空 ， 视 作 一 个 新 的 监控 周期 开启 。 


第 四 层级 : 可 以 视 统计 信息 收集 的 时 间 窗 口 而 定 ， 如 果 有 时 间 窗 口 ， 也 尽 可 能 去 做 一 次 统计 信息 的 重新 收集 。 


四 


@ia 示 对 于 空 表 即使 收集 了 统计 信息 ， 也 尽 可 能 地 删除 掉 ， 因 为 这 个 统计 信息 没有 意义 ， 还 不 如 SQL 执行 时 动态 采样 。 


5. 索 引 的 收集 策略 


索引 的 统计 信息 收集 策略 相对 要 简单 一 些 ， 因 为 其 变化 的 场景 也 少 。 与 表 相 关 的 变化 动作 已 经 在 表 的 收集 策略 中 进行 了 履 盖 收集 ， 不 必 再 做 单独 的 考虑 。 主 要 考虑 的 是 索引 独特 的 变化 场景 : 


:索引 新 建 ; 


“ 索引 重建 。 


该 两 种 场景 都 是 要 进行 对 应 索引 的 统计 信息 重新 收集 。 比 较 幸 运 的 是 ， 从 Oracle 10g 开 始 ， 该 两 种 场景 下 ，Oracle 都 会 自动 完成 统计 信息 的 重新 收集 ， 不 必 人 工 干预 。 如 下 示例 : 


10:46:42 SQL> select index name, num rows, last analyzed 
10:46:47 2 from user ind statistics 

10:46:47 3 where table name = 'ALEX T401'; 

INDEX_NRMP NUM ROWS LAST ANALYZED 

IDX ALFEX T401 _ID 100000 2014-03-14 10:44:54 
10:46:50 SQL> alter index idx alex t401 id rebuild online; 
Index altered 

10:47:24 SQL> select index name, num rows, last analyzed 
10:47:28 2 from user ind statistics 

10:47:28 3 where table name = 'ALEX T401'; 


INDEX_NAME NUM ROWS LAST ANALYZED 
IDX ALEX T401 ID 100000 2014-03-14 10:47:23 
4.3.3 ”管理 收集 方式 


从 收集 策略 的 定制 可 以 看 到 ， 我 们 的 收集 方式 主要 可 以 分 为 三 种 类 型 的 场景 : 
“ 系统 表 的 收集 场景 ; 
: 索引 的 单独 收集 场景 (因为 基本 上 都 是 10g 以 上 的 版 本 ， 这 个 场景 基本 上 没有 了 ) ; 


“ 表 (包括: 普通 表 、 分 区 表 ) 的 收集 场景 。 


以 上 三 种 场景 的 收集 方式 都 是 使 用 系统 工具 包 DBMS_STATS 来 完成 ， 接 下 来 我 们 将 围绕 这 个 系统 包 分 场景 展开 介绍 。 


1. 系 统 表 的 收集 


当 默 认 使 用 CBO 优 化 器 的 时 候 ， 建 议 还 是 尽 可 能 地 收集 数据 字典 表 和 固定 对 象 的 统计 信息 ， 以 保证 SQL 语句 访问 数据 字典 的 性 能 最 优 。 


(1) 数据 字典 表 的 收集 方式 


可 以 直接 使 用 如 下 语句 来 完成 收集 ， 必 要 时 指定 相关 参数 。 


SQL> exec dbms_ stats.gather dictionary stats; 


如 果 是 11g9 以 上 的 版 本 ， 也 可 以 直接 设置 全 局 的 首选 项 ， 让 Oracle 自 动 进 行 收集 工 作 。 


SQL> exec dbms_stats.set global prefs (pname=>'AUTOSTATS TARGET',pvalue=>'ORACLE'); 


(2) 固定 对 象 的 收集 方式 


数据 库 固定 对 象 即 为 动态 性 能 表 ， 其 统计 信息 的 收集 与 更 新 ， 可 以 保障 使 用 AWR、ASH 等 工具 的 效率 更 高 。 


SQL> exec dbms stats.gather fixed objects stats; 


2. 索 引 的 单独 收集 


在 前 面 的 收集 策略 中 已 经 提 到 ， 索 引 统计 信息 的 收集 过 程 ， 基 本 上 在 表 的 统计 信息 收集 过 程 中 已 经 进行 了 关联 收集 ， 其 关联 收集 的 方式 可 以 参照 表 的 收集 方式 。 我 们 先 来 说 说 索引 单独 进行 统计 信息 收 


集 方式 吧 。 


SQL> exec dbms stats.gather index stats('alex','idx alex t401 id'); 


如 果 收 集 过 程 需要 提高 效率 ， 可 以 指定 DEGREE 参 数 ， 其 他 相关 的 一 些 参 数 设置 ， 可 以 参考 dbms_stats.gather_table_stats 过 程 的 介绍 。 


3. 表 的 收集 


各 参数 的 配置 也 略 有 不 同 ， 


说 起 表 的 统计 信息 收集 方式 ， 不 得 不 先 说 说 DBMS_STATS 包 提供 的 用 作 收 集 表 的 统计 信息 的 过 程 dbms_stats.gather_table_stats。 在 不 同 版 本 的 Oracle 数 据 库 中 ， 


体 说 


明 如 表 4-2 所 示 。 


参 数 
ownname 
tabname 


partname 


estimate percent 


block sample 


method opt 


4 YI 


仿 依 


信人 信人 全 人 


表 4-2 ”gather_table_stats 参 数 说 明 


说 。 明 
分 析 目 标 表 的 属 主 
分 析 目 标 表 表 名 
分 析 目 标 表 分 区 的 分 区 名 
收集 过 程 的 采样 率 ， 取 值 范围 区 间 为 : [0.000001, 100] 
该 参数 的 默认 值 为 DBMS_STATS.AUTO _SAMPLE SIZE， 由 Oracle 决定 合 


适 的 采样 率 

该 参数 取 NULL 值 时 ,采样 率 为 100%。 可 设置 的 最 低 值 为 1% 

当 进行 一 张大 表 统 计 信 息 收集 的 时 候 ， 如 上 次 成 功 收集 时 间 过 长 (比如 : 超 

过 10 分钟)， 无 法 保证 在 可 接受 时 间 内 完成 100% 的 采样 率 ， 则 按 下 例 公式 适 

当 降 低 采 样 率 

采样 率 = (预期 收集 时 间 /上 次 收集 时 间 ) X 上 次 采样 率 

该 参数 在 11g 中 ， 可 采用 默认 值 AUTO_SAMPLE SIZE， 其 可 达到 之 前 版 本 

100% 采样 率 的 准确 性 ， 资 源 消耗 只 有 之 前 版 本 的 10% 

该 参数 控制 是 否 采 用 随机 块 采 样 替代 随机 行 采 样 

随机 块 采 样 性 能 较 好 ， 但 准确 性 不 可 靠 

随机 行 采 样 性 能 较 低 ， 但 准确 性 较 高 

默认 值 为 FALSE， 采 用 随机 行 采样 ， 建 议 使 用 默认 值 即 可 

该 参数 决定 直方 图 建立 的 方式 ， 其 格式 为 : 

FOR ALL [INDEXED | HIDDEN] COLUMNS SIZE [<N> | REPEAT | AUTO] 

[INDEX |HIDDEN] 子 句 设置 : 

w for all columns: 统计 所 有 列 的 直方 图 

w for all indexed columns: 统计 所 有 索引 列 的 直方 图 

w for all hidden columns: 统计 看 不 到 的 列 的 直方 图 

[<N> | REPEAT | AUTO] 子 句 设置 

v <N>: 设置 直方 图 收集 级 别 ，N 取 值 范围 为 [1254]，1 为 不 收集 

w REPEAT: 只 在 有 直方 图 的 列 上 创建 直方 图 

w AUTO : 由 Oracle 按 数 据 分 布 及 使 用 情况 决定 哪些 列 要 创建 直方 图 ， 即 
Oracle 判断 N 的 取 值 ， 其 为 默认 值 

因为 创建 直方 图 是 一 个 相对 费时 费力 的 过 程 ， 建 议 使 用 FOR ALL COLUMNS 

SIZE REPEAT， 首 次 直方 图 建立 由 人 工 评估 创建 


degree 


granularity 


cascade 


stattab 


statid 


statown 


no_ invalidate 


force 


信 统计 信息 收集 的 并 行 度 


说 明 


ALTER TABLE 指定 的 并 行 度 


今 建议 按照 表 的 大 小 和 收集 时 间 窗 口 的 条 


级 别 选 择 不 同 的 并 行 度 


邻 收集 细 粒 度 
w 对 表 为 ALL 


v 对 分 区 为 PARTITION 
v 对 子 分 区 为 SUBPARTITION 


统计 信息 收集 后 ， 


分 今 | 今 信 


得 历史 统计 信息 


10g 以 上 版 本 的 库 可 不 使 用 该 参数 ， 可 通过 DBA_TAB_STATS 


参数 决定 在 收集 表 的 统计 信息 的 同时 是 否 关 联 收集 索引 统计 信息 
按照 收集 策略 ， 该 参数 必须 设置 为 TRUE 


保存 历史 统计 信息 的 表 


信 建议 不 论 什 么 版 本 的 数据 库 ， 都 建立 统计 信息 备份 表 ， 便 于 管理 


统计 信息 收集 后 ， 


得 历史 统计 信息 


保存 历史 统计 信息 的 记录 ID 


信 建议 不 论 什么 版 本 的 数据 库 ， 都 建立 统计 信息 备份 表 ， 便 于 管理 


仿 统计 信息 收集 后 ， 


保存 历史 统计 信息 的 表 的 属 主 


( 续 ) 


默认 值 为 NULL， 表 示 取 CREATE TABLE 或 


条 件 ， 根 据 具 体 情况 设置 级 别 ， 不同 的 


_HISTORY 获 


10g 以 上 版 本 的 库 可 不 使 用 该 参数 ， 可 通过 DBA_TAB_STATS_HISTORY 获 


令 10g 以 上 版 本 的 库 可 不 使 用 该 参数 ， 可 通过 DBA_TAB_STATS_HISTORY 获 


得 历史 统计 信息 


oe 置 为 FALS 


本 二 | 全 机 二 


免 不 必 要 的 混乱 


么 版 本 
参数 设置 是 否 使 相关 游标 失效 


的 数据 库 ， 都 建立 统计 信息 备份 表 ， 便 于 管 


E 


归 总 一 下 上 述 表格 的 参数 建议 ， 可 以 大 致 得 到 如 下 各 个 版 本 表 统 计 信息 收集 的 脚本 。 需 要 注意 的 是 ， 在 开始 收集 之 前 ， 需 要 做 好 相关 备份 工作 ， 这 将 在 备份 策略 中 介绍 


该 参数 决定 是 否 忽 略 锁定 ， 强 制 收集 (即使 表 锁 住 了 也 收集 统计 信息 ) 


9i 库 不 支持 锁定 统计 信息 ， 无 此 参数 。10g 以 上 版 本 的 库 建 议 为 FALSE， 避 


-- Oracle 11g 收 集 脚本 
begin 


dbms_stats.gather table stats (Ownname => 'ALEX', 
tabname => 'ALEX T401', 
estimate_percent - = dbms stats.auto Ee size, 
method opt => 'FOR ALL COLUMNS SIZE 1' 
degree => 1, 
cascade => true, 
no invalidate => false); 


end; 
=-- Oracle 10g 收 集 脚本 
begin 


dbms_stats.gather table_stats (ownname => 'ALEX' 
tabname => 'ALEX T401', 
estimate percent - => 100, 
method opt => "FOR ALL COLUMNS SIZE 1' 
degree => 1, 
cascade => true, 
no invalidate => false); 


engd; 
-- Oracle 9i 收 集 脚本 


begin 


dbms_stats.gather table stats (ownname => 'ALEX', 
tabname => 'ALEX T401', 
estimate percent - => 100, 
method opt => "FOR ALL COLUMNS SIZE 1" 
degree => 1, 
cascade => true, 
no invalidate => false); 


end; 


在 收集 策略 中 ,我们 也 有 介绍 对 于 分 


区 表 的 收集 策略 可 以 参照 普通 表 来 做 ， 那 么 对 于 单个 分 


息 需要 删除 掉 ， 避 免 错误 的 引导 优化 器 行为 。 


区 的 收集 ， 则 需要 在 上 述 脚本 中 指定 partname 参 数 。 同 时 ， 收 集 策略 中 提 到 ， 对 了 


F 空 表 或 者 空 分 区 的 统计 信 


一 - 空 表 统计 信息 删除 脚本 
begin 


dbms_stats.delete table stats (ownname => 'ALEX', 


tabname 
cascade 


cascade _ 


=> 'ALEX T401', 
colums => true, 
indexes => true, 


cascade parts => true); 


end; 


为 什么 对 于 空 表 要 删除 其 统计 信息 呢 ? 


为 空 表 可 能 是 一 些 临 时 表 ， 其 上 的 数据 生命 周期 比较 短 ， 在 我 们 一 个 收集 周期 内 ， 它 的 数据 量 会 有 很 大 的 一 个 突变 过 程 ， 数 据 的 变化 很 频繁 ， 且 每 次 的 变化 量 


不 一 致 ， 变 化 量 差别 很 大 ， 这 样 我 们 就 很 难 有 效 地 把 握 它 的 统计 信息 的 准确 ， 不 得 不 在 SQL 执行 过 程 中 采用 动态 采样 进行 收集 


动态 采样 (Dynamic Sampling) 技术 的 最 初 提出 是 在 Oracle 9i R2， 在 段 对 象 没 有 分 析 的 情况 下 ， 为 了 使 CBO 优 化 器 得 到 足够 的 信息 ， 以 保证 做 出 正确 的 执行 计划 而 出 现 的 一 种 技术 ， 可 以 把 它 看 做 
统计 信息 分 析 手 段 的 一 种 补充 。 当 段 对 象 没有 统计 信息 时 ， 动 态 采样 技术 可 以 通过 直接 从 需要 分 析 的 对 象 上 采样 收集 ， 来 获得 优化 器 所 需要 的 统计 信息 。 


通常 情况 下 ， 动 态 采样 是 不 得 已 而 为 之 的 ， 如 果 我 们 能 够 收集 到 准确 的 统计 信息 ， 那 么 还 是 收集 吧 ， 因 为 这 个 比 动 态 采样 要 来 得 精确 得 多 。 


如 果 说 临时 表 业 务 数据 变化 是 有 规律 可 循 的 ， 那 么 这 时 候 可 以 在 数据 导入 完毕 后 ， 收 集 统计 信息 并 锁定 统计 信息 ， 效 果 往 往 比 动态 采样 会 更 好 。 


动态 采样 的 结果 会 在 输出 的 执行 计划 中 显示 如 下 信息 


- dynamic sampling used for this statement 


4.3.4 制定 备份 策略 


的 生产 数据 ， 我 们 


是 


制定 合适 的 备份 策略 ， 这 个 工作 似乎 要 比 收集 工作 本 身 还 
怎么 可 能 不 完善 一 下 备份 的 策略 呢 ? 


要 。 优 秀 的 统计 信息 数据 ， 其 价值 完全 不 亚 于 生产 数据 ， 可 以 说 统计 信息 数据 就 是 DBA 的 生产 数据 。 那 么 对 于 这 


ba 
由 


1. 自 动 管理 备份 


Oracle 从 10g 开 始 ， 当 一 个 表 重 新 收集 了 新 的 统计 信息 ， 则 该 表 的 旧 统 计 信 息 会 自动 备份 起 来 。 如 果 SQL 依赖 该 旧 统计 信息 ， 导 致 查询 出 现 性 能 问题 ， 可 以 直接 恢复 旧 的 统计 信息 ， 以 最 快 的 速度 完成 
性 能 问题 的 修复 。 统 计 信息 自动 备份 信息 可 以 通过 dba_tab _stats_history 视 图 来 查询 获取 。 


SQL> select table name, stats update time from dba tab stats history 
2 where table name='ALEX T401'; 

TABLE NAME STATS UPDATE, TIME 

ALEX T401 10-3 月 -14 10.48.09.693820 上 :00 
ALEX T401 10-3 月 -14 05.15.26.379975 TT :00 
ALEX_T401 11-3 月 -14 10.50.55.854227 :00 
ALEX T401 13-3 月 -14 04.55.14.742198 - :00 
ALEX T401 13-3 月 -14 04.55.24.495222 TT :00 
ALEX T401 14-3 月 -14 09.49.34.516780 | :00 
ALEX T401 14-3 月 -14 09.57.52.224687 | :00 
ALEX T401 14-3 月 -14 10.40.53.209920 :00 
ALEX T401 14-3 月 -14 10.41.04.997321 :00 
RLEX_T401 24-3 月 -14 11.37.05.301278 :| 400 


下 面 我 们 通过 一 个 实例 来 介绍 一 下 这 个 功能 的 使 用 吧 。 


步骤 1 ” 先 修 改 自动 备份 集 保留 的 时 间 ， 默 认 情况 为 31 天 ， 这 显然 是 不 够 的 ， 在 确保 SYSAUX 表 空间 有 足够 空间 的 前 提 下 ， 尽 可 能 保留 更 长 时 间 的 统计 信息 备份 集 。 如 下 ， 设 置 保留 周期 为 365 天 ， 并 查 
询 过 期 时 间 。 


SQL> execute dbms stats.alter stats history _retention (365) 7 

SQL> select dbms stats.get stats history retention retention days, 
2 dbms stats. get : stats history : availability ava date from dual; 

RETENTION 1 DAYS AVA DATE 


365 23-3 月 -13 11.22.41.539214000 下 午 +08:00 


步骤 2 创建 一 个 测试 表 alex_t402， 并 建立 索引 ， 收 集 统计 信息 。 


SQL> create table alex t402 as select * from dba objects; 
SQL> create index idx : alex : t402 id on alex t402 (object id) 7 


SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (OWNNAME => 'ALEX', 
TABNAME => 'ALEX T402', 
4 ESTIMATE PERCENT => DBMS STATS.AUTO SAMPLE SIZE, 
5 METHOD OPT => 'FOR ALL COLUMNS SIZE 1', 
6 DEGREE => 1, 
CRSCRDE => TRUE, 
8 NO INVALIDATE ~ => FALSE); 
9 END; 
40 8 


步骤 3 ”查询 确认 表 和 索引 的 统计 信息 ， 可 以 看 到 统计 信息 已 经 成 功 收集 ， 并 被 自动 备份 。 


SQL> select table name, num rows, blocks from dba tab statistics 
2 where table name='ALEX T402'; 0 

TABLE NAME NUM ROWS BLOCKS 

ALEX T402 61597 946 

SQL> select index .name, blevel, leaf blocks, distinct keys 
2 from dba ind statistics where table name='ALEX T402'; 

INDEX_ NAME BLEVEL LEAF :1 BLOCKS DISTINCT 1 KEYS 

IDX ALEX T402 ID 1 137 61592 

SQL> select table name, stats update time from dba tab stats history 
2 where table name='ALEX T402'; 

TABLE NAME STATS_ UPDATE TIME 


ALEX_T402 24-3 月 -14 01.55.03.361752 下 午 +08:00 


步骤 4 TRUNCATE 表 alex_t402， 再 重新 收集 一 下 统计 信息 ， 然 后 确认 统计 信息 的 备份 。 可 以 看 到 统计 信息 被 更 新 了 ， 同 时 进行 了 备份 。 此 时 如 果 需 要 之 前 的 备份 ， 可 以 进行 恢复 。 


SQL> select table name, num rows, blocks from dba tab statistics 
2 where table name='ALEX T402'; 

TABLE NAME NUM_ ROWS BLOCKS 

ALEX T402 0 0 

SQL> select index Name, blevel, leaf blocks, distinct keys 
2 from dba - ind : statistics where table name='ALEX T402'; 

INDEX NAME BLEVEL LEAF :1 BLOCKS DISTINCT "KEYS 

IDX ALEX T402 ID 0 0 0 

SQL> select table :> name, stats update time from dba tab stats history 
2 where table name='ALEX T402'; 

TABLE NAME STATS_UPDATE TIME 

ALEX T402 24-3 月 -14 01.55.03.361752 下 午 +08:00 

ALEX_T402 24-3 月 -14 02.03.41.680532 下 午 +08:00 


步骤 5 ”恢复 之 前 的 备份 ， 可 以 看 到 统计 信息 又 回 到 了 TRUNCATE 操 作 之 前 。 


SQL> begin 
2 dbms_stats.restore table stats (ownname => 'ALEX', 
3 tabname => 'ALEX T402', 
4 as_of timestamp => '24-3 月 -14 01.55.03.361752 下 午 +08:00'); 
5 end; 
6 / 
PL/SQL Procedure successfully completed 
SQL> select table name, num rows, blocks from dba tab statistics 
2 where table name='ALEX T402'; 
TABLE NAME "NUM ROWS ~ BLOCKS 
ALEX T402 61597 946 
SQL> select index name, blevel, leaf blocks, distinct keys 
2 from dba ind statistics where table name='ALEX T402'; 
INDEX NAME BLEVEL LEAF BLOCKS DISTINCT KEYS 


IDX ALEX T402_ID 


步骤 6 时间 长 了 ， 统 计 信息 备份 集会 比较 多 ， 当 不 知道 如 何 


区 分 的 时 候 ， 可 以 通过 如 下 的 步骤 来 比较 两 个 备份 的 差异 。 


SQL> select report 


县 from table (qbms_stats.diff table stats in history('ALEX', 

3 'ALEX T402', 

4 '24-3 月 -14 01.55.03.361752 下 午 +08:00'， 

号 124-3 月 -14 02.03.41.680532 下 午 +08:00')); 
2. 手 工 管理 备份 


从 自动 管理 的 方法 来 看 ， 时 间 长 了 可 能 会 比较 混乱 ， 还 是 需 


手工 进行 一 些 必要 的 


F 预 ， 使 管理 工作 更 为 简单 。 比 如 : 新 建 一 个 统计 信息 备份 明细 表 ， 记 录 下 来 该 统计 信息 收集 的 概要 信息 。 另 外 ， 如 


果 数 据 库 还 是 Oracle 9i 的 话 ， 那 么 是 没有 这 个 功能 的 ， 我 们 还 是 需要 手工 来 进行 备份 集 的 管理 工作 。 


同样 ， 我 们 通过 一 个 实例 
管理 的 往往 会 更 精细 一 些 。 具 体 步骤 如 下 所 示 : 


步骤 1 


来 说 明 一 下 手工 管理 备份 将 如 何 来 操作 吧 。 其 实 ， 在 道理 上 来 说 是 非常 简单 的 


我 们 需要 创建 一 个 备份 表 STATS_BAK， 这 也 是 可 以 精细 的 一 个 地 方 ， 我 们 可 以 创建 一 组 表 ,来 


， 就 是 变通 的 来 实现 Oracle 


动 统计 信息 备份 的 方法 。 然 而 ， 对 了 


F 一 个 有 经 验 的 DBA 来 说 ， 手 工 


区 别 的 管理 不 同 分 类 或 者 不 同 寻 


要 级 别 的 统计 信息 。 


SQL> exec dbms_ stats.create stat table (ownname 
stattab 


=> 'ALEX', 
=> 'STATS_BAK') 


export_table_stats 备 份 表 ALEX_T402 的 统计 信息 。 请 注意 ， 这 里 我 们 可 以 在 参数 statid 上 指定 个 性 化 的 标签 便于 


区 分 ， 当 然 也 可 以 像 自动 管理 一 样 新 建 一 个 概要 表 来 记录 概要 信息 。 


步骤 2 使 
SQL> begin 
2 dbms stats.export table stats (ownname => 'ALEX', 
3 tabname => 'ALEX T402', 
4 stattab => 'STATS BAK', 
号 Statown = TEXT 
6 cascade => TRUE, 
statid => 'ALEX T402 20140324054500'); 
8 
9 end; 
10 / 


PL/SQL procedure successfully completed 


步骤 3 ”在 需要 恢复 旧 的 统计 信息 的 时 候 ， 可 以 使 


import_table_stats 过 程 指 定 相 应 的 备份 集 标签 进行 恢复 。 


SQL> BEGIN 
县 dbms_ stats.import table stats (ownname => 'ALEX', 
3 ~ tabname => 'ALEX T402', 
4 cascade => TRUE, 
5 stattab => 'STATS BAK', 
6 statid => 'ALEX T402 20140324054500', 
要 statown => 'ALEX'); 
8 END; 
SF 


步骤 4 ”对 于 两 个 备份 的 


区 别 比较 可 以 简单 地 通过 查询 备份 表 STATS_BAK 来 进行 对 比 ， 


也 可 以 通过 dbms stats 包 来 帮助 完成 。 


SQL> select report 


妥 from table (dbms stats.diff table stats in stattab('ALEX', 
3 'ALEX T402', 
4 'STATS_BAK', 
5 'STATS_BAK', 
6 NULL, 
7 'ALEX T402 20140324054500', 
8 'ALEX T402 20140324063000', 
9 'ALEX", 
10 'ALEX')); 
从 便于 管理 与 区 分 的 角度 来 看 ， 手 工 管理 是 比较 不 错 的 选择 ， 但 是 需要 额外 开发 一 套 统计 信息 收集 与 备份 管理 的 程序 来 完成 。 一 方面 ， 保 有 手工 管理 的 灵活 性 ; 另 一 方面 ， 也 可 以 实现 自动 作业 运行 ， 
避免 过 多 的 人 工 干预 。 
3 .统计 信息 锁定 


以 上 说 到 的 统计 信息 收集 过 程 ， 我 们 都 是 细 化 到 段 对 象 的 粒度 ， 为 什么 不 进行 


户 级 和 数据 库 级 的 统计 信息 收集 呢 ? 我 们 说 不 是 不 可 以 ， 只 是 不 推荐 。 细 粒度 的 管理 方式 比较 利于 问题 的 把 握 和 追溯 ， 


对 于 业务 的 统计 信息 收集 与 备份 策略 ， 不 要 怕 麻 烦 ， 需 要 将 粒度 细 化 到 表 级 。 
如 果 说 是 通过 一 套 自 开发 的 自动 备份 的 程序 或 者 用 户 级 的 收集 方式 来 进行 收集 的 


个 别 表 进 行 统计 信息 锁定 ， 避 免 统计 信息 被 更 新 。 


话 ， 我 们 不 可 避免 地 要 面 对 一 个 问题 ， 就 是 大 部 分 表 的 统计 信息 需要 更 新 ， 但 有 个 别 表 不 想 更 新 。 此 时 ， 我 们 就 需要 对 


SQL> exec dbms_ stats.lock table stats (ownname => "DEVMGR'， 
tabname => 'ALEX T402') 
SQL> select table name, stattype locked from dba tab statistics 
2 where table name='ALEX T402"; na 


TABLE_NRAME STATTYPE LOCKED 
ALEX_T402 ALL 
SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (OWNNAME => 'ALEX', 
六 加 TABNAME ~ => 'ALEX T402', 
4 ESTIMATE PERCENT => DBMS_ STATS.AUTO SAMPLE SIZE, 


5 METHOD OPT => 'FOR ALL COLUMNS SIZE 1', 
6 DEGREE => 1, 

学 CASCADE => TRUE, 

8 NO_INVALIDATE => FALSE); 


10 / 

ORA-20005: object statistics are locked (stattype = ALL) 
ORA-06512: at "SYS.DBMS STATS", line 15027 

ORA-06512: at "SYS.DBMS_STATS", line 15049 

ORA-06512: at line 2 


如 果 表 的 统计 信息 被 锁定 了 ， 再 进行 收集 的 话 ， 就 会 报 ORA-20005 的 错误 出 来 。 对 于 某 些 统计 信息 敏感 的 核心 业务 表 ， 可 以 考虑 进行 必要 的 锁定 。 


4. 收 集 与 发 布 


在 Oracle 119 R2 版 本 之 前 ， 统 计 信息 收集 与 发 布 基本 上 就 是 一 个 概念 ， 除 非 使 用 备份 策略 ， 先 备份 旧 的 ， 再 收集 新 的 ， 然 后 恢复 旧 的 。 但 是 ， 从 119 R2 开 始 ，Oracle 可 以 将 收集 与 发 布 两 件 事情 分 离 
开 来 了 。 


这 里 我 们 需要 先 设置 对 象 表 的 首选 项 ， 当 然 也 可 以 设置 全 局 的 首选 项 ， 但 是 出 于 细 粒 度 化 的 精细 管理 方式 ， 我 们 还 是 设置 表 级 的 ， 设 置 其 PUBLISH 状 态 为 FALSE， 统 计 信 息 需 确认 再 发 布 。 通 过 以 下 的 
设置 ， 我 们 就 成 功 地 实现 了 统计 信息 的 收集 与 发 布 工作 的 分 离 。 


SQL> exec dbms stats.set table prefs('DEVMGR', 'ALEX T402', 
二 'PUBLISH', 'FALSE') 
SQL> select dbms_ stats.get prefs('PUBLISH', 'DEVMGR', 'ALEX T402') 
2 pub stat from dual; 
PUB STRAT 


收集 完 统计 信息 后 ， 如 下 所 示 ， 可 以 看 到 在 统计 信息 视图 user tab_statistics 中 并 没有 相关 信息 ， 而 新 收集 的 统计 信息 保存 到 了 待 审 核 的 统计 信息 视图 user tab_pending_stats 中 。 


SQL> select table name, num rows, last analyzed 

2 from user tab statistics where table name='ALEX T402'; 
TABLE NAME NUM ROWS LAST ANALYZED 
ALEX T402 
SQL> select table name, num rows, last analyzed 

2 from user tab pending stats where table name='ALEX T402'; 
TABLE NAME NUM ROWS LAST ANALYZED 


ALEX T402 85706 3/24/2014 17:30:00 


如 果 审核 通过 ， 进 行 统计 信息 发 布 ， 那 么 刚才 收集 的 统计 信息 将 从 待定 视图 中 迁移 到 真正 的 统计 信息 视图 中 。 迁 移 步 又 与 验证 如 下 所 示 : 


SQL> exec dbms stats.publish pending stats('DEVMGR', 'ALEX T402'); 
SQL> select table name, num rows, last analyzed 

2 from user tab statistics where table name='ALEX T402'; 
TABLE_ NAME ~ NUM ROWS LAST ANALYZED ~ - 
ALEX T402 85706 3/24/2014 17:30:00 
SQL> select table name, num rows, last analyzed 

2 from user tab pending stats where table name='ALEX T402'; 
no rows selected 


设置 这 么 麻烦 的 东西 ， 有 什么 好 处 吗 ” 当 然 是 好 处 不 小 了 ， 实 现 收集 与 发 布 的 分 离 ， 不 仅仅 是 为 了 统计 信息 的 审核 和 备份 元 余 ， 它 还 有 一 个 更 重要 的 作用 就 是 统计 信息 变化 对 SQL 语句 的 影响 性 能 分 
析 。 如 何 来 实现 呢 ? 


我 们 可 以 开 两 个 同样 的 会 话 ， 会 话 级 的 参数 optimizer_use_pending_statistics， 一 个 设置 为 true (优化 器 可 以 使 用 待 发 布 的 统计 信息 ) ， 一 个 设置 为 false (不 可 以 使 用 待 发 布 的 统计 信息 ) ， 对 比 其 执 
行 计划 的 差别 。 如 果 为 true 的 会 话 执行 计划 优 于 为 false 的 会 话 ， 那 么 说 明 待 发 布 的 统计 信息 是 有 利于 SQL 性 能 提升 的 ， 可 以 发 布 ， 反 之 则 不 可 以 发 布 。 


Session A: 
SQL> alter session set optimizer use pending statistics = true; 
Session B: 
SQL> alter session set optimizer use pending statistics = false; 


有 了 这 个 统计 信息 审核 把 关 的 功能 ,数据 库 架 构 师 的 工作 将 变 得 美好 一 些 ， 这 相当 于 一 个 对 象 有 两 套 统计 信息 ， 可 以 择优 录取 。 


4.3.5 ”收集 直方 图 


[ 


在 第 2 章 的 索引 设计 中 ， 我 们 已 经 提 及 并 验证 过 直方 图 对 执行 计划 的 影响 了 。 当 某 个 列 又 出 现在 SQL 的 WHERE 子 句 的 谓词 中 ， 如 果 在 没有 直方 图 的 情况 下 ，Oracle 对 这 个 列 的 区 分 度 取 的 是 平均 值 。 当 
该 列 的 数据 分 布 存在 倾斜 时 ， 即 列 的 不 同 值 出 现 数量 差异 较 大 ， 这 样 无 法 体现 SQL 语句 执行 时 实际 绑 定 值 的 占 比 情况 ， 直 接 导致 执行 计划 跑 偏 ， 该 走 索引 的 走 了 全 表 扫描 ， 该 走 全 表 扫描 的 走 了 索引 。 


有 哪些 情况 要 考虑 收集 直方 图 信息 呢 ? 简单 地 来 说， 就 是 列 上 的 数据 分 布 发 生 严重 倾斜， 影响 到 执行 计划 生成 的 时 候 。 前 面 说 到 过 ， 设 计 高 效 的 表 和 索引 是 不 应 该 出 现 这 样 的 问题 的 ， 但 是 实际 应 用 中 
往往 又 是 很 难 杜绝 的 ， 那 么 如 何 来 平衡 呢 ? 


我 们 知道 收集 列 的 直方 图 是 一 个 费时 费力 的 操作 ， 能 不 做 就 不 要 做 ， 已 经 做 过 了 的 就 接着 做 下 去 ， 就 是 “最 优化 现状 ”原则 。 


在 收集 统计 信息 的 过 程 中 ， 指 定 METHOD OPT 参 数 为 “FOR ALL COLUMNS SIZE REPEAT” 即 可 。SQL 语 句 如 下 所 示 : 


BEGIN 
DBMS STATS .GATHER TABLE STATS (ONNNRAME => 'ALEX', 

> TABNAME, => 'ALEX T401', 
ESTIMATE PERCENT => DBMS STATS.AUTO SAMPLE SIZE, 
METHOD OPT => 'FOR ALL COLUMNS SIZE REPEAT", 
DEGREE => 1, 
CASCADE, => TRUE, 
NO_INVALIDATE => FALSE); 

END; 


4.4 执行 计划 管理 


执行 计划 是 优化 程序 执行 SQL 语句 并 执行 某 一 操作 时 所 执行 的 一 组 步骤 。 当 执行 某 一 SQL 语句 时 ， 服 务 器 将 执行 由 优化 器 创建 的 计划 步 又 ， 每 一 步 又 要 么 从 数据 库 物 理 检索 数据 行 ， 要 么 以 某 种 方式 为 
户 准备 数据 行 。 


优秀 的 执行 计划 是 我 们 前 面 优化 器 配置 和 统计 信息 管理 工作 的 最 终 产 物 ， 可 以 说 如 果 我 们 前 面 的 工作 精细 地 完成 了 ， 正 常情 况 下 的 优秀 执行 计划 是 可 以 预期 的 。 然 而 ，Oracle 再 优秀 也 只 是 一 套 软 


件 ，CBO 优 化 器 再 完美 也 只 是 一 套 算法 ， 即 使 最 优 执行 计划 是 必然 的 ， 也 不 可 避免 偶然 的 情况 。 这 样 就 需要 DBA 们 对 执行 计划 的 有 效 干预 。 
4.4.1 获取 执行 计划 


执行 计划 获取 这 个 狐 似 很 简单 的 问题 ， 在 很 多 文档 和 书籍 上 都 提供 了 很 多 的 方法 ， 比 如 : 


. EXPLAIN PLAN; 

动态 性 能 视图 ; 

- DBMS_XPLAN 包 ; 

“ SQILXPlus 工 具 的 AUTOTRACE 功 能 ; 
" AWR 报 告 视图 ; 


:SQL 跟踪 与 事件 跟踪 。 


相信 方法 还 不 只 我 以 上 罗列 的 这 些 。 但 是 ， 我 们 必须 要 明确 ， 得 到 的 执行 计划 是 否 是 真实 可 靠 的 执行 计划 呢 ? 有 的 时 候 使 用 不 同 的 方法 获取 相同 的 SQL 语句 执行 计划 ， 其 结果 是 不 一 样 的 。 


那么 ， 如 何 识别 获取 的 执行 计划 是 有 效 可 靠 的 呢 ? 推荐 一 个 简单 的 原则 : SQL 语句 实际 执行 过 的 ， 并 在 执行 过 程 中 获取 的 执行 计划 是 比较 有 效 可 靠 的 。 但 这 种 有 效 可 靠 也 是 有 时 效 性 的 ， 如 果 数 据 发 生 


变化 ， 统 计 信息 变化 了 ， 执 行 计划 就 有 可 能 变化 。 


来 比较 区 分 一 下 上 述 几 种 方法 吧 。 通 过 EXPLAIN PLAN 命令 ， 是 无 须 执行 该 SQL 语句 的 ， 这 和 我 们 的 原则 是 有 悖 的 ， 其 获取 的 执行 计划 是 不 可 靠 的 。 另 一 方 | 
题 的 ， 自 动 显示 转换 蔡 代 隐 式 转换 ， 无 法 使 用 绑 定 变量 窥探 ， 直 接 导致 执行 计划 不 准确 。 


动态 性 能 视图 (比如 : V$SQL_PLAN) 存储 的 是 SQL 语句 在 数据 库 实 际 执行 过 的 计划 ， 是 比较 可 靠 的 。 


面 来 看 ， 该 方法 在 处 理 绑 定 变量 上 是 存在 问 


DBMS _XPLAN 包 只 是 一 种 接口 的 方法 ， 用 来 显示 由 EXPLAIN PLAN 命令 和 V$SQL_ PLAN 查询 以 及 AWR 生 成 的 执行 计划 ， 其 获取 的 执行 计划 可 靠 性 需要 由 实际 的 方法 来 决定 。 


SQL*Plus 工 具 的 AUTOTRACE 功 能 是 实际 工作 中 使 用 得 比较 多 的 方法 ， 因 为 非常 便捷 ， 其 可 靠 性 也 是 需要 实际 执行 SQL 语句 来 保证 ， 而 不 能 只 是 解析 一 下 而 已 。 


AWR 报 告 视图 其 本 质 就 是 动态 性 能 视图 的 历史 数据 ， 也 是 比较 可 靠 的 。 但 因为 是 历史 的 ， 所 以 无 法 保证 其 时 效 性 。 


SQL 跟踪 与 事件 跟踪 是 从 SQL 执行 过 程 中 获取 执行 计划 ， 在 不 出 现 Bug 的 前 提 下 ， 也 是 比较 可 靠 的 方法 。 遗 憾 的 是 ，Oracle 官 方 只 支持 SQL 跟踪 的 方式 。 然 而 ， 这 并 不 影响 我 们 使 用 10046 和 10053 等 有 


效 的 事件 跟踪 工具 。 


需要 特别 注意 的 是 ， 数 据 库 环境 不 同 了 ， 即 使 是 一 点 微小 的 变化 ， 执 行 计划 也 是 有 可 能 会 变化 的 。 执 行 计划 是 一 个 非常 敏感 的 东西 ， 其 依赖 的 影响 因素 也 比较 多 ， 也 正 因 为 此 我 们 前 面 一 直 在 说 需要 将 


CBO 优 化 器 和 统计 信息 管理 的 工作 尽 可 能 地 做 精细 一 些 。 


4.4.2 ”固化 执行 计划 


执行 计划 的 重要 性 是 不 言 而 喻 的 ，CBO 优 化 器 和 统计 信息 的 精细 管理 ， 是 从 直接 源头 上 对 执行 计划 的 优化 干预 ， 那 么 还 有 哪些 优化 干预 可 以 做 呢 ? 


' 使 用 SQL PROFILE; 


“ 使 用 SPM 稳 定 执行 计划 ; 


: 给 SQL 加 提示 HINT; 


“ 使 用 OUTLINE 存 储 大 纲 ; 


. 要 求 开发 重新 编写 SQL。 


这 些 方法 中 直接 要 求 开发 重 写 SQL 是 最 好 不 过 的 方法 ， 但 是 实际 情况 往往 是 很 不 容易 做 到 的 。 正 如 前 面 说 到 技术 推动 的 业务 的 行为 ， 那 么 只 能 退 而 求 其 次 给 SQL 加 上 HINT 关 键 字 ， 来 干预 执行 计划 。 然 


而 ， 通 过 个 别 的 HINT 关 键 字 是 很 难 有 效 地 干预 较为 复杂 的 SQL 语句 的 ， 如 果 业 务 系统 是 外 购 的， 那么 这 些 都 变 得 不 可 能 实现 了 。 


从 数据 库 层 面 入 手 ， 我 们 可 以 有 效 把 握 的 将 是 以 下 三 种 方法 。 这 三 种 方法 与 其 说 是 干预 执行 计划 ， 不 如 说 是 固化 执行 计划 ， 强 制 执 行 计划 按照 预定 的 轨道 来 走 。 


“ 使 用 SPM 稳 定 执行 计划 ; 
“ 使 用 OUTLINE 存 储 大 纲 ; 


“ 使 用 SQL PROFILE。 


1.SPM 固 化 


SPM 工 具 是 Oracle 119 引 进 的 一 个 新 特性 ， 当 一 个 已 经 生成 好 的 执行 计划 


由 于 底层 因素 的 更 改 而 需要 更 新 时 ， 新 计划 不 会 立即 实施 ，Oracle 会 对 这 个 新 计划 进行 评估 ， 仅 当 它 比 原 有 计划 更 有 效 


时 ，Oracle 才 会 实施 新 计划 。 此 外 ， 还 可 以 使 用 工具 和 接口 来 查看 每 个 执行 计划 的 历史 记录 ， 以 及 这 些 计划 的 对 比 情况 。 听 上 去 是 不 是 很 像 前 面 说 到 的 统计 信息 备份 和 审查 后 发 布 的 功能 ?是 的 ， 在 119 


中 ，Oracle 很 大 程度 上 强化 了 查询 优化 器 相关 的 管理 。 


如 图 4-4 所 示 ， 对 于 执行 超过 一 次 的 SQL 语句 ，CBO 优 化 器 会 维护 SQL 语句 的 执行 计划 的 历史 记录 。SQL 语 句 在 被 记录 后 再 次 分 析 或 执行 时 ， 会 被 识别 为 可 重复 SQL 语句 。SQL 语 名 被 识别 为 可 重复 语句 


之 后 ， 优 化 器 生成 的 各 种 计划 会 被 维护 为 一 个 执行 计划 历史 记录 ， 它 包含 优化 器 重新 生成 执行 计划 所 用 的 相关 信息 (比如 : SQL 文本 、 大 纲 、 绑 定 变量 和 编译 环境 ) ， 并 将 该 计划 存储 在 数据 库 一 个 称 为 


SQL 管理 库 (SMB) 的 逻辑 结构 中 。 经 过 验证 后 ， 集 成 到 基线 ， 作 为 SQL 优化 的 指引 。 


SYSAUX 表 空间 


概要 文件 


了 计划 历史 记录 


可 重复 的 


SQL 语句 SQL 优化 


图 4-4 SPM 基 线 管 理 


SMB 将 存储 每 类 查询 的 所 有 计划 ， 会 导致 SYSAUX 表 空间 变 得 十 分 庞大 。 因 此 ， 需 要 控制 SMB 存 储 的 计划 的 数量 ， 尽 可 能 地 使 用 手动 加 载 应 设 定 基线 的 查询 ， 避 免 不 必要 的 自动 加 载 。 


通过 一 个 实例 来 了 解 一 下 吧 。 


步骤 1 关闭 Oracle 数 据 库 自动 捕获 功能 ， 然 后 新 建 测试 表 alex_t403， 并 完成 第 一 个 查询 操作 。 此 时 查询 SQL 的 执行 计划 被 记录 到 动态 性 能 视图 ， 但 不 会 被 SPM 自 动 捕 获 到 。 


SQL> alter system set optimizer capture sql plan baselines=false; 
SQL> create table alex t403 as select * from dba objects; 
SQL> exec dbms stats.gather table stats (user, 'ALEX T403', 
加 cascade => true) 
SQL> select * from alex t403 where object id=1001; 


步骤 2 手工 加 载 上 述 查询 SQL 的 执行 计划 到 SMB， 第 一 次 加 载 的 会 被 直接 设置 为 基线 。 


SQL> declare 
2 report number; 
3 begin 
4 report := DBMS_SPM.load plans from cursor cache(sql id => 'dqhacr590z6yn'); 
5 dbms output.put line (report); 
6 END; 一 本 
Ei 
SQL> select plan name, enabled, accepted, fixed, autopurge 
全 from dba sql plan baselines 
3 where sql handle = 'SQL 3ae8bf49566f2781'; 
PLAN NAME ENABLED ACCEPTED FIXED AUTOPURGE 


SQL PLAN 3pu5z95b6y9w133fcb758 YES YES NO YES 


这 里 需要 注意 几 个 参数 : 

“ ENABLED: 表示 该 执行 计划 记录 是 否 为 可 启用 状态 ，YES 为 可 启用 ，NO 为 不 可 ; 
" ACCEPTED: 表示 该 记录 是 否 被 评估 后 接受 ，YES 为 可 以 ，NO 为 不 可 ; 

:. FIXED: 表示 记录 的 优先 级 ，YES 是 优先 级 较 高 ，NO 为 一 般 ; 

: AUTOPURGE: 表示 过 期 后 自动 清除 。 


此 时 加 载 的 执行 计划 为 全 表 扫 描 : 


SQL> select * 
党 from table (dbms xplan.display sql plan baseline( 
ke "SQL 3ae8bf49566f2781', 'SQL PLAN 3pu5z95b6y9w133fcb758")); 
SQL handle: SQL 3ae8bf49566f2781 
SQL text: Select * from alex t403 where object id=1001 
Plan name: SQL PLAN _ 3pu5z95b6Yy9w133fcb758 Plan id: 872200024 
Enabled: YES NO d: YES Origin: MANUAL-LOAD 


| Bytes | Cost (%CPU)| Time | 
| SELECT STATEMENT | | 1024 | 207K| 278 
| TABLE ACCESS FULL| ALEX T403 | 1024 | 207K| 278 


1 - filter ("OBJECT ID"=1001) 


步骤 3 创建 索引 后 ， 重 新 执行 上 述 查 询 ，SPM 认 为 其 为 可 重复 的 SQL 语句 ， 自 动 建立 新 的 计划 记录 ， 但 是 在 评估 之 前 并 不 会 被 接受 (ACCEPTED=NO) 。 


SQL> create index idx alex t403 id on alex t403 (object id) 7 
SQL> exec dbms stats.gather table stats (User， 'ALEX T403', 
本 思 cascade => true) 
SQL> select * from alex t403 where object id=1001; 
SQL> select plan name, enabled, accepted, fixed, autopurge 
2 from dba sql plan baselines 


3 where sql handle = "SQL 3ae8bf49566f2781 "7 


PLAN_NAME ENABLED ACCEPTED FIXED AUTOPURGE 
SQL PLAN 3pu5z95b6y9w133fcb758 YES YES NO YES 
SQL PLAN 3pu5z95b6y9w17b8e34eb YES NO NO YES 


步骤 4 对 新 的 执行 计划 记录 进行 评审 演化 ， 此 后 ， 新 计划 被 接受 ， 成 为 新 的 可 用 基线 。 当 再 执行 上 述 查询 SQL 语句 的 时 候 ， 会 选择 COST 较 小 的 新 的 基线 。 


SQL> declare 
2 report clob; 
3 begin 
4 report := dbms_spm.evolve sql plan baseline(sql handle => 
"SQL 3ae8bf49566f2781"'); 
5 dbms output.put line (report); 
6 end; 
是 


SQL> select plan name, enabled, accepted, fixed, autopurge 
2 from dba sql plan baselines 
3 where sql handle = "SQL 3ae8bf49566f2781"'; 


PLAN NAME ~ ENABLED ACCEPTED FIXED AUTOPURGI 
SQL PLAN 3pu5z95b6y9w133fcb758 YES YES NO YES 
SQL PLAN 3pu5z95b6y9w17b8e34eb YES YES NO YES 
SQL> select * 
2 from table (dbms xplan.display sql plan baseline( 
3 "SQL 3ae8bf49566f2781', 'SQL PLAN 3pu5z95b6y9w133fcb758"')); 


: SQL 3ae8bf49566f2781 
SQL text: select * from alex t403 where object id=1001 


Plan name: SQL PLAN 3pu5z95b6Yy9w17b8e34eb Plan id: 2072917227 

Enabled: YES Fixed: NO Accepted: YES Origin: AUTO-CAPTURE 

Plan hash value: 2768498200 

| Id | Operation | Name | Rows | Bytes | Cost ($)| 
| 0 | SELECT STATEMENT | | 1024 | 207K| | 
| 1 | TABLE ACCESS BY INDEX ROWID| ALEX T403 | 1024 | 207K| 二 1 
[| INDEX RANGE SCAN | IDX ALEX T403 ID | 410 | | 二 1 


2 - access ("OBJECT ID"=1001) 


步骤 5 ”此 时 ， 如 果 需 要 固化 较 优 的 新 的 执行 计划 为 唯一 基线 ， 可 以 将 旧 的 记录 的 ENABLED 设 置 为 NO， 或 者 直接 删除 旧 的 记录 ， 也 可 以 修改 新 的 计划 的 FIXED 为 YES， 提 高 其 优先 级 。 执 行 代码 如 下 所 


泵 : 
一 -修改 旧 计划 的 ENABLED 参 数 
declare 
report number; 
begin 
report := dbms_spm.alter sql plan baseline( 
sql handle => "SQL 3ae8bf49566f£2781', 
Plan name => 'SQL BPLAN 3pu5z95b6y9w133fcb758', 
attribute name => 'ENABLED', 
attribute value => 'NO'); 
end; 
一 -删除 旧 计划 
declare 
report number; 
begin 
report := dbms_spm.drop sql plan baseline( 
sql handle => "SQL 3ae8bf49566f2781', 
plan name => 'SQL PLAN 3pu5z95b6y9w133fcb758'); 
dbms_output.put line (report); 
end; 


至 此 ， 我 们 已 经 完成 了 一 次 SPM 固 化 较 优 执行 计划 的 操作 。 但 是 ， 我 们 前 面 说 到 执行 计划 是 否 较 优 也 是 有 其 时 效 性 的 ， 就 像 我们 前 后 两 个 基线 ， 第 一 个 基线 在 索引 创建 之 前 是 较 优 的 ， 索 引 创建 之 后 就 
过 期 了 ， 需 要 新 的 基线 ， 因 此 我 们 需要 定期 进行 基线 的 评估 和 演化 。 


同时 ， 这 样 的 演化 工作 是 不 建议 在 生产 环境 进行 的 ， 可 以 在 同 构 的 测试 库 进行 ， 完 成 后 ， 再 导入 到 生产 环境 进行 固化 。 具 体 SQL 语句 如 下 所 示 : 


一 -创建 SPM 备 份 用 表 
begin 
Gbms_spm.create stgtab baseline( 
加 | table name => 'alex_ spm stgtab', 
table owner => USER, 
tablespace name => 'USERS'); 


end; 
一 在 测试 库 备份 优化 后 的 SPM 记 录 
declare 
report number; 
begin 
report := dbms_spm.pack stgtab baseline( 
table name => 'alex spm stgtab', 
table owner => USER, 
sql_handle => 'SQL 5f66ccc0e5e6838e') 7 
dbms_output.put line (report) 7 


end7 
一 在 生产 库 导 入 优化 后 的 SPM 记 录 
declare report number; 
begin 
report := dbms_spm.unpack stgtab baseline( 
table name => 'alex spm stgtab', 
table owner => USER, 
sql handle => 'SQL 3ae8bf49566f2781'); 
Gbms output.put line (report); 
end; 


2.OUTLINE 固 化 


OUTLINE 大 纲 固化 执行 计划 的 方法 想必 是 再 熟悉 不 过 的 了 ， 在 SPM 出 现 之 前 ， 这 可 以 算是 最 好 的 方法 。 这 种 方法 的 原理 也 是 比较 简单 的 ， 就 是 给 既定 的 SQL 语句 在 后 台 添 加 若干 HINT 关 键 字 ， 来 进行 
执行 计划 的 干预 。 


下 面 是 一 个 OUTLINE 的 例子 ， 为 上 面 同样 的 SQL 查询 语句 建立 OUTLINE， 并 启用 。 该 OUTLINE 初 始 化 创建 完成 后 为 UNUSED 状 态 ， 只 有 当 该 SQL 语句 被 再 次 执行 的 时 候 ， 才 会 起 作用 ， 即 为 USED 状 


SQL> create or replace outline alex t403 outln 
2 for category cate outline on 
3 select * from alex t403 where object id=1001; 
SQL> alter system set use stored outlines = cate outline; 
SQL> select name, sql text, used, category 
2 from user outlines 
3 where name = 'ALEX T403 OUTLN'; 
NAME USED CATEGORY 


ALEX T403 OUTLN USED CATE OUTLINE 


当 OUTLINE 生 成 之 


后 ， 会 在 outln 


SQL> select ol name, hint#, hint text 

2 from outin.ol$hints 

3 where ol name = 'ALEX T403 OUTLN'; 
OL_NAME, ~ HINT# HINT TEXT 
ALEX_T403_OUTLN 1 INDEX RS ASC(@"SEL$1" "ALEX TA403"@"SELS$S1" .... 
ALEX_T403_OUTLN 2 OUTLINE LEAF (Ge"SELS1") 加 
ALEX T403_OUTLN 3 ALL ROWS 
ALEX_T403_OUTLN 4 OPT PARAM('optimizer index caching' 100) 

5 OPT PARAM('optimizer index cost adj' 10) 


ALEX_T403_OUTLN 


一 般 来 说 ， 此 时 的 OUTLINE 是 不 能 直接 使 用 的 ， 因 


为 往往 不 能 直接 生成 有 效 的 执行 计划 ， 否 则 我 们 也 不 用 借助 OUTLINE 工 


户 下 的 三 个 表 (ol$、ol$hints、ol$nodes) 中 建立 相关 的 信息 。 这 里 最 值得 关注 的 是 ol$hints 表 中 存储 的 HINT 关 键 字 信息 ， 关 键 字 信 息 查 询 结果 如 下 所 示 : 


了 。 这 里 ， 需 要 我 们 手工 去 修改 ol$hints 表 中 HINT 信 息 ， 当 然 这 也 是 需 


严格 测试 过 的 。 如 果 没 有 测试 库 的 情况 下 ， 可 以 复制 一 个 私有 的 OUTLINE， 进 行 测试 修改 后 ， 覆 盖 原 有 OUTLINE; 如 果 有 测试 库 的 话 ， 可 以 直接 导出 导入 上 述 OUTLN 下 三 个 表 的 数据 即 可 。 


值得 注意 的 是 ， 当 OUTLINE 与 SPM 并 存 的 时 候 ，OUTLINE 的 优先 级 是 比较 高 的 ，SQL 执 行 的 是 OUTLINE 的 规则 。 


3.SQL Profile 固 化 

SQL Profile 是 Oracle 在 10g 中 推出 的 一 个 用 于 固化 执行 计划 的 新 工具 ， 准 确 地 来 说 ， 它 更 像 一 个 过 渡 期 产品 ， 兼 容 了 OUTLINE 的 HINT 关 键 字 干预 的 特点 ， 却 又 不 如 SPM 工 具 的 完善 ， 可 以 算是 介 于 两 
者 之 间 的 一 个 存在 。 因 此 ， 在 实际 应 用 中 不 推荐 使 用 该 工具 。 

如 果 不 得 不 使 用 SQL Profile 的 时 候 ， 尽 量 使 用 mport_sql_profile 的 方式 ， 直 接 指定 HINT 关 键 字 ， 避 免 opt_estimate ( 按 一 个 估算 的 百分比 来 调整 一 些 统计 数据 ) 的 设置 导致 中 心计 划 不 固定 和 不 稳 


ma 
自 。 


SQL> declare 


2 vhints sys.sqlprof attr; 

3 begin 加 

4 vhints := sys.sqlprof attr('ALL ROWS', 

5 和 'INDEX (ALEX T403, IDX ALEX T403 ID)'); 

6 dbms sqltune.import sql profilel(sql text ”=> 

"select * from alex t403 where object ig=1001', 

7 Profile =>vhints, 

8 name => 'ALEX T403 SQLP', 
9 force match => true)? 

10 end; 

11 / 


SQL Profile 和 SPM 实 际 上 是 合并 同时 起 作用 ，SPM 可 以 视 为 一 个 升级 进化 版 ，SPM 的 使 
的 。 


OUTLINE 和 SQL Profile 只 要 HINT 语 法 没有 错误 ， 都 是 会 生效 的 ， 即 使 发 生 对 象 变化 的 时 候 ， 比 如 : 索引 被 删除 了 。OUTLINE 和 
可 能 是 另 一 套 极 差 的 执行 计划 ， 这 也 是 其 不 足 之 处 ， 不 能 像 SPM 一 样 随机 应 变 。 


而 实际 执行 的 情况 才 


对 于 119 的 数据 库 ，SPM 是 一 个 不 错 的 选择 ， 值 得 推荐 。 
一 个 中 间 产 品 ， 不 如 还 是 使 用 OUTLINE， 原 理 基本 上 是 一 样 | 


的 。 


4.5 ”性 能 影响 分 析 


在 前 面 的 章节 中 ， 我 们 不 只 一 次 地 提 到 性 能 影响 分 析 这 个 


优先 级 是 高 


对 于 10g 以 下 的 版 本 ， 没 有 更 多 的 选择 ，OUTLINE 将 是 推荐 工 


比较 小 的 变更 的 评估 ， 比 如 : 增删 索引 等 。4.6 节 将 介绍 Database Replay， 其 主要 


下 面 以 SPA 为 例 ， 介 绍 性 能 影响 分 析 工具 的 使 用 。 


说 到 SQL 的 性 能 影响 分 析 ，MySQL 的 DBA 们 可 能 会 比 Oracle 的 做 得 更 好 一 些 ， 因 为 Oracl 
发 压力 足够 大 的 时 候 ， 微 小 的 问题 都 可 能 引起 严重 的 后 果 ， 这 也 正 是 为 什么 要 做 压力 测试 原 


因 


从 另 一 个 角度 来 思考 的 话 ， 如 果 我 们 能 够 把 性 能 影响 分 析 细 化 到 每 一 次 的 数据 结构 变更 上 ， 那 么 就 不 会 面临 大 


幸运 的 是 ， 现 在 我 们 有 不 少 自动 化 工具 可 以 去 选择 ， 我 们 这 里 不 介绍 第 三 方 的 工具 


e 数 所 


因 。 


SQL Profile 的 ， 


也 就 是 说 在 三 种 工具 中 ，SQL Profile 的 优先 级 是 最 低 的 ，OUTLINE 则 是 最 高 


SQL Profile 不 会 


自动 重新 获取 基线 ， 而 是 保持 原 有 的 规则 仍然 有 效 ， 然 


。 比 较 


念 。 简 单 地 来 说 ， 性 能 影响 分 析 就 是 确定 在 数据 库 发 生变 更 后 ， 其 性 能 是 否 没有 变 差 。 本 节 我 们 将 介绍 SPA 工 
作 于 数据 库 级 别 的 变更 的 评估 ， 比 如 : 数据 库 升级 和 压力 测试 等 。 


了 , 而 


围绕 Oracle 


身 的 工具 来 


说 到 自动 的 评估 工 


，SPA 是 个 不 错 的 选择 ， 从 Oracle 10g 的 版 本 开始 ， 我 们 就 可 以 使 


这 个 工具 


“ 生产 数据 库 ， 简 称 生产 库 ， 主 要 作用 就 是 抓 取 待 分 析 的 SQL 语句 ; 
“ 性 能 分 析 数 据 库 ， 


“ 重演 测试 数据 库 ， 简 称 测试 库 ， 应 该 是 与 生产 库 同 构 的 ， 最 好 是 生产 的 一 个 备 库 ， 用 于 


图 


如 


4-5 所 示 ， 先 通过 一 个 流程 图 


来 了 解 一 下 使 


SPA 进 行 性 能 影响 分 析 的 工作 原理 吧 。 


接 下 来 做 一 个 实例 来 说 明 一 下 分 析 的 过 程 吧 ， 删 


除 索引 idx_alex_t403 id 的 应 上 


场景 。 


首先 需要 关注 一 下 生产 库 ， 在 其 上 周期 性 的 抓 取 相关 SQL 语句 。 该 索引 相关 的 操作 ， 都 是 基于 表 alex_t403 的 应 用 ， 


具体 步骤 如 下 所 示 : 


宁 议 亦 


基 克 六 


规模 的 性 旬 
展开 。 


监 粹 的 是 10g 的 数据 库 ， 很 多 人 可 能 会 考虑 使 用 SQL Profile， 与 其 选择 


的 使 用 ，SPA 主 要 帮助 一 些 


居 库 的 优化 器 比较 强大 ， 可 以 掩盖 掉 一 些 有 问题 的 SQL 可 能 造成 的 不 良 影响 。 然 而 ， 当 一 套数 据 库 系统 的 并 


评估 了， 也 就 是 说 ， 随 时 去 做 性 能 影响 的 评估 工作 。 当 然 ， 这 是 费时 费力 的 。 


了 ， 但 是 必须 使 


简称 分 析 库 (必须 是 11g 及 以 上 版 本 ) ， 驱 动 SQL 重演 ， 记 录 对 比 结果 ， 并 输出 对 比 报告 ; 


更 模拟 和 SQL 重演 。 


11g 的 库 作为 辅助 。 我 们 先 定义 三 种 角色 的 数据 库 : 


此 


到 该 表 的 SQL 语句 都 可 能 受到 索引 删除 的 影响 ， 那 么 都 将 成 为 被 抓 取 的 对 象 。 


< 序 分 析 库 测试 库 


导入 SQLSET 信 息 


创建 SQLSET 


创建 分 析 作 业 


抓 取 缓 存 的 SQL 到 SQLSET 


驱动 SQL 重 演 


周期 性 抓 取 SQL 到 SQLSET 自动 保存 结果 


导出 SQLSET 信 息 


驱动 SQL 重演 


自动 保存 结果 


对 比分 析 报 告 


4-5 SPA 性 能 影响 分 析 流 程 图 


步骤 1 创建 一 个 名 称 为 SQLSET_ALEX_T403 的 SQLSET，SQL 如 下 : 


begin 
dbms_sqltune.create sqlset( 
sqlset name => 'SQLSET ALEX T403', 
sqlset_owner => user); 
eng; 


步骤 2 加 载 当 前 CURSOR CACHE 内 与 表 alex_t403 相 关 的 SQL 到 SQLSET 中 : 


declare cursql dbms_ sqltune.sqlset cursor; 
V_cnt number; 
V_sql varchar2 (1000); 
begin 
V_sql:=" (upper (sql text) LIKE ''%ALEX T403%"'')"'; 
open cursql for 
select value (p) 
from table (dbms_sqltune.select cursor cachel(v sql, 'ALL')) p; 
dbms_sqltune.load sqlset( 
sqlset name => 'SQLSET ALEX T403', 
populate cursor => cursql, 
commit rows => 100, 
sqlset_ owner => user); 
close cursql; 
commit; 
end; 


步骤 3 增 量 抓 取 相 关 SQL 语 句 ， 每 分 钟 1 次 ,持续 10 分 钟 。 可 根据 需求 自 定义 time _limit (持续 时 长 ) 和 repeat_interval ( 抓 取 频 率 ) 参数 : 


declare 
V_sql varchar2(1000); 
begin 
V_sql:=' (upper (sql text) LIKE ''%ALEX T403%"'')"; 
dbms_sqltune.capture cursor cache sqlset( 
sqlset name => 'SQLSET ALEX T403', 
time limit => 600, 0 
repeat interval => 60, 
Capture option => "MERGE'， 
capture mode => dbms_sqltune.mode accumulate stats, 
basic filter => v_sql, 
sqlset_owner => user); 


步骤 4 ”创建 备份 表 STGTAB_ALEX_T403， 并 将 抓 取 的 SQL 备 份 到 该 表 : 


begin 


Gbms_sqltune.create stgtab sqlset( 
table name => 'STGTAB ALEX T403', 
schema name => user); 
end; 
begin 
Gbms_sqltune.pack stgtab sqlset( 
sqlset name => 'SQLSET ALEX T403', 
sqlset owner => user, 
staging table name => 'STGTAB ALFEX T403', 
staging schema owner => user); 
end; 


步骤 5 导出 备份 表 STGTAB_ALEX_T403: 


然后 ， 我 们 就 需要 关注 分 析 库 和 测试 库 了 ， 以 分 析 库 作为 辅助 ， 驱 动 SQLSET 在 测试 库 上 重演 ， 结 果 和 报告 在 分 析 库 上 记录 和 输出 。 


步骤 6 将 备份 出 来 的 表 STGTAB_ALEX_T403 导 入 分 析 库 ， 新 建 一 个 分 析 库 到 测试 库 的 一 个 public database link: DBL_TEST: 


步骤 7 在 分 析 库 新 建 一 个 与 生产 库 同名 的 SQLSET， 并 将 备份 表 的 信息 导入 其 中 : 


begin 
Gbms_sqltune.create sqlset( 
sqlset name => 'SQLSET ALEX T403', 
sqlset owner => user); 


end; 
begin 
Gbms_sqltune.unpack stgtab sqlset( 
sqlset_name 加 => 'SQLSET ALEX T403', 

sqlset owner => user, 
replace => True, 
staging table name => 'STGTAB ALEX T403', 
staging schema owner => user); 加 

end; 


步骤 8 ”在 分 析 库 新 建 一 个 分 析 驱 动作 业 TASK_ALEX_T403， 用 来 在 测试 库 上 重演 SQLSET: 


declare 
V task varchar2 (100); 
begin 
Vv task := dbms_sqlpa.create analysis task( 
sqlset name => 'SQLSET ALEX T403', 
task name => 'TASK ALEX T403'); 
end; 


步骤 9 ”索引 删除 前 ， 在 分 析 库 上 通过 DB_LINK 重 演 SQLSET， 获 取 执 行 结果 信息 (run_bef) ; 在 与 生产 库 同 构 的 测试 库 上 模拟 索引 idx_alex_t403_id 删 除 操作 ;索引 删除 后 ， 在 分 析 库 上 通过 DB_LINK 
演 SQLSET， 再 次 获取 执行 结果 信息 (run_aft) : 


由 


begin 
dbms_sqlpa.execute analysis task( 
~ task name => 'TASK ALEX T403', 
execution type => "TEST EXECUTE', 
execution name => 'run bef', 
execution params => dbms advisor.arglist ('DATABASE LINK', 
'DBL TEST')); 
end; 
drop index idx alex t403 id; 
begin i 了 
Gbms_sqlpa.execute _ analysis task( 
~ task name => 'TASK ALEX T403', 
execution type => "TEST EXECUTE', 
execution name => 'run aft', 
execution params => dbms advisor.arglist ('DATABASE LINK', 
'DBL TEST')); 
end; 到 


步骤 10 ”对 比分 析 run_bef 和 run_aft 的 结果 ， 并 输出 对 比 报告 : 


begin 
dbms_sqlpa.execute analysis _ task( 
task name => 'TASK ALEX T403', 
execution type => 'COMPARE PERFORMANCE'); 
end; 
select dbms sqlpa.report analysis task(task name => 'TASK ALEX T403', 
= Eype => 'text', 和 
section => 'summary') 
from dual; 


以 上 输出 的 对 比分 析 报 告 主体 部 分 如 下 所 示 ， 其 中 我 们 需要 重点 关注 报告 汇总 部 分 。 从 本 例 中 可 以 看 到 ， 索 引 删 除 后 ， 表 ALEX_T403 上 的 所 有 操作 ， 其 整体 性 能 下 降 了 154.83%。 整 体 来 看 ， 删 除 该 索 
引 是 不 可 行 的 。 同 时 ， 有 5 条 SQL 语句 受到 影响 ， 性 能 下 降 明显 。 


Projected Workload Change Impact: 


Overall Impact -154.83% 
Improvement Impact : 0% 
Regression Impact : =~154.83$% 


SQL Statement Count 


SQL Category SQL Count Plan Change Count 


Overall Ly 4 
Regressed 5 4 
with Errors 2 0 
Unsupported 4 0 


Top 5 SQL Sorted by Absolute Value of Change Impact on the Workload 


| | | Impact on | Execution | Metric | Metric | Impact | Plan | 


| object id | sql id | Workload | Frequency | Before | After | on SQL | Change | 
| 26 | 56awfkwry6a88 | -133.64% | 4 1 0 | 429000 | -42900000% | Y | 
| 29 | 8rp9a0kuw4a7v | -81% | 1 | 303000 | 329000 | -8.58% | n | 
| 33 | cj9n39tlujds9 | -5.92% | 下 0 | 19000 | -1900000% | Y | 
| 34 | dqhacr590z6yn | -5.92% | 4 0 | 19000 | -1900000% | y | 
| 32 | bz3zah8naujpa | -1.25% | 1 | 18000 | 22000 | -22.22% | Y | 


Note: time statistics are displayed in microseconds 


另 一 方面 来 看 ， 如 果 整 体 性 能 是 能 接受 的 ， 只 有 个 别 SQL 语 句 的 性 能 是 变 差 了 ， 那 么 可 以 用 前 面 介 绍 的 OUTLINE 和 SPM 工 具 来 固化 SQL 的 执行 计划 。 以 上 我 们 就 完成 了 一 次 数据 库 变更 的 性 能 影响 分 
析 。 


如 果 上 述 的 SQL 语句 比较 多 呢 ? 生成 报告 再 分 析 可 能 就 不 是 太 明智 了 ， 就 好 像 要 分 析 大 量 的 AWR 报 告 ， 一 个 一 个 地 去 生成 ， 就 显得 笨拙 了 。 那 我 们 可 以 直接 去 相关 表 和 视图 中 查询 吧 。 一 般 来 说 ， 我 们 
会 去 对 比 变更 前 后 的 执行 计划 变化 、 执 行 时 间 变 化 、 物 理 读 写 变化 、 逻 辑 读 写 变化 ， 下 面 三 个 表 和 视图 可 以 提供 相关 的 信息 。 


[ 


“SYS.WRHS$_SQLTEXT 


* DBA_ADVISOR_SQLSTATS 


` DBA_ADVISOR_SQLPLANS 


可 能 有 不 少 文档 会 介绍 说 SPA 可 以 用 于 数据 库 升级 等 大 规模 的 操作 ， 但 是 我 们 说 那 不 是 SPA 的 强项 ， 它 更 应 该 是 关注 在 SQL 语 句 的 性 能 影响 分 析 上 ， 更 注重 精细 化 的 分 析 。 而 大 规模 的 应 F 


库 重 放 (Database Replay) 去 做 吧 。 


4.6 ”数据 库 重 放 


数据 库 重 放 (Database Replay) 功能 是 Oracle 在 119 版 本 中 引进 的 一 个 新 特性 ， 比 较 普遍 地 
个 角度 来 看 ， 比 较 大 就 很 难 做 到 像 SPA 那 样 比较 精细 了 ， 相 对 来 阅 ，Database Replay 更 像 是 一 个 比较 粗放 的 工 . 


估算 性 质 的 结果 。 这 里 我 们 将 介绍 使 


4.6.1 ”普通 数据 库 重 放 特 性 


数据 库 重 放 功 能 来 实现 高 并 发 问题 的 模拟 和 解决 。 


于 数据 库 升 级 (10g 到 


， 就 交 给 数据 


11g 的 升级 ) 、 数 据 库 迁 移 (硬件 的 变更 ) 、 压 力 测试 等 比较 大 的 场景 变化 。 另 一 
映 生产 库 完全 一 致 的 场景 ， 它 更 倾向 于 提供 给 用 户 一 个 


， 即 使 重 放 也 不 可 能 毫 无 遗漏 地 


如 图 4-6 所 示 ， 数 据 库 重 放 可 以 分 为 捕获 和 重 放 两 个 阶段 ， 两 个 阶段 分 别 对 应 一 套 Oracle 数 据 库 内 置 系统 : 捕获 系统 和 重 放 系统 ， 该 两 个 系统 就 是 实现 数据 库 重 放 的 核心 所 在 。 


捕获 系统 各 项 功能 可 通过 dbms_workload_capture 工 具 包 来 实现 ， 


dba_workload _replays 视 图 进行 监控 。 


(1) 捕获 阶段 


步骤 @I"]: 在 开始 之 前 ， 需 要 对 生产 库 做 一 次 全 备 ， 如 果 


产生 额外 的 负载 压力 ， 可 能 导致 测试 结果 不 准 。 


步骤 @: 开启 捕获 系统 的 捕获 进程 ， 这 里 可 以 选择 设置 过 滤 条 件 ， 以 减少 捕获 文件 的 产生 


运行 过 程 和 进度 可 以 通过 dba_workload captures 视 图 来 监控 ; 


放 系 统 则 可 通过 dbms_workload_replay 工 具 包 来 实现 各 项 功能 ， 


为 在 


如 果 是 压力 测试 的 重 放 ， 则 最 好 不 


放 过 程 中 ,会 


。 当 然 我 们 这 里 是 需要 模拟 高 并 发 的 压力 ， 不 需要 选择 过 滤器 。 


步骤 @: 产生 生产 压力 。 这 里 需要 注意 的 是 ，Database Replay 和 诸多 类 似 的 工具 一 样 ， 不 可 能 做 到 完全 的 捕获 ， 是 会 存在 少量 的 SQL 遗漏 的 。 当 然 ， 对 于 高 并 发 压力 测试 工作 ， 我 们 不 需要 精细 化 比 


较 。 


步骤 @: 关闭 捕获 进程 ， 最 终 在 OS 上 的 捕获 


录 生 成 捕获 文件 。 当 然 ， 捕 获 目 录 是 需要 事先 在 Oracle 数 


个 会 话 会 生成 一 个 记录 文件 。Oracle 并 没有 对 这 些 文件 加 密 ， 通 过 第 三 方 工 | 


D 备 份 


捕获 目录 |G 
捕获 文件 
捕获 文件 
| 捕获 文件 | 
四 关闭 捕获 
办 生成 捕获 
2 文件 
捕获 


系统 


和 很 多 第 三 方 工具 一 样 ， 数 据 库 重 放 的 实质 也 是 通过 前 台 服 务 器 进程 捕获 各 个 会 话 的 执行 跟踪 文件 ， 并 进行 重 放 。 然 而 ， 所 不 一 样 的 是 数据 库 重 放 的 捕获 只 会 产生 5% 的 额 儿 
过 10046 事 件 跟踪 捕获 则 会 产生 20% 的 额外 负载 ， 从 某 种 意义 上 来 说 ， 这 样 已 经 失去 模拟 测试 的 意义 了 。 另 一 方 
注 的 是 ， 捕 获 文件 的 存储 卷 需要 保留 足够 的 空间 ， 对 于 一 个 并 发 压力 较 大 的 系统 ， 单 位 时 间 内 产生 的 文件 量 是 比较 大 的 。 


为 、 会 话 的 切换 、LOB 的 功能 操作 等 。 值 得 : 


图 4-6 


居 库 创建 好 的 。 捕 获 文件 是 一 个 个 名 称 诸如 “wcr_3qz68h0000002.rec” 的 二 进 制 记 录 文件 ,每 


或 许可 以 解析 出 这 些 文件 的 内 容 。 


重 放 环境 


处 
| 捕获 文件 
捕获 文件 


重 放 库 


0 分析 并 生成 报告 


Database Replay 流 程 图 


负载 ， 而 很 多 第 三 方 工具 通 
户 会 话 的 登录 和 注销 行 


， 数 据 库 重 放 支持 的 项 目 也 更 多 ， 除 了 本 地 事务 以 外 ， 还 包括 


步骤 @: 恢复 生产 库 到 重 放 环境 ， 同 时 迁移 捕获 目录 到 重 放 环境 ， 此 时 捕获 目录 可 以 称 为 重 放 目录 ， 捕 获 文件 也 可 以 称 为 重 放 文 件 。 


(2) 重 放 阶 段 


步骤 @: 重 放 系统 需要 对 捕获 文件 进行 一 些 解析 ， 并 将 捕获 信息 导入 到 


放 库 ， 使 得 


放 系 统 、 重 放 库 和 重 放 客 


端 能 够 识别 捕获 文件 。 


ul 


步骤 @: 初始 化 重 放 。 


步骤 @: 设置 重 放 的 配置 。 这 个 步骤 也 是 重 放 阶 段 最 重要 的 ， 通 过 该 步骤 的 设置 ， 可 以 区 分 重 放 工作 的 目的 。 比 如 : 升级 操作 就 可 以 完全 按照 捕获 文件 进行 同步 重 放 ， 而 对 于 压力 测试 则 需要 进行 异步 
重 放 ， 同 时 设置 压力 值 。 该 工作 可 以 通过 dbms_workload replay.prepare_replay 过 程 来 进行 设置 。 这 里 我 们 需要 重点 关注 几 个 参数 : 


“ Synchronization: 当 进 行 同步 等 压力 重 放 的 时 候 ， 可 以 设置 该 参数 为 TRUE ， 反 之 ， 进 行 压 力 测试 的 时 候 ， 需 要 设置 为 FALSE。 
“ connect_time_scale: 连接 时 间 比 例 ， 设 置 为 50， 则 连接 时 间 比 例 为 50%， 在 捕获 阶段 4 分 钟 之 后 才 会 登录 的 会 话 ， 现 在 2 分 钟 后 就 会 登录 。 该 参数 的 设置 ， 可 以 起 到 加 压 的 效果 。 


“think_time_scale: 会 话 内 临近 2 个 SQL 过 程 间 的 间隔 时 间 比 例 ， 比 如 : 捕获 阶段 2 个 SQL 之 间 为 10 秒 ， 设 置 该 参数 为 50 ( 即 : 50%) ， 则 时 间 间 隔 为 5 秒 ， 如 设置 为 0， 其 间隔 变 为 0 秒 。 设 置 该 参数 可 以 有 
效 地 缩短 重 放 的 时 间 。 


“scale_up_multiplier: 指定 查询 压力 的 倍数 ， 该 参数 仅 对 只 读 操作 有 效 ， 设 置 为 3， 则 查询 操作 在 重 放 阶 段 为 捕获 阶段 的 3 倍 压力 。 


在 做 整 库 的 高 并 发 压力 模拟 测试 的 时 候 ， 可 以 合理 设置 connect_ time_scale 参 数 以 及 think _time_scale 参 数 的 组 合 配 比 。 


步骤 @: 在 重 放 机 上 开启 wrc 重 放 客 户 端 ， 开 启 的 客户 端 数 量 可 以 参考 wrc 自 我 评估 值 ， 也 需要 考虑 压力 情况 。 如 果 是 做 压力 测试 的 模拟 ， 则 wrc 客 户 端 不 要 和 数据 库 放 在 同一 台 服务 器 上 ， 避 免 造 成 数 
据 库 服务 器 的 额外 负载 ， 导 致 测试 结果 偏差 。 


步骤 @: 根据 捕获 信息 和 重 放 信息 ， 可 以 生成 对 比 性 能 报告 。 


(3) 重 放 功 能 示例 


抽象 的 功能 介绍 可 能 并 不 能 让 大 家 对 数据 库 重 放 功能 有 较 深 的 理解 ， 还 是 通过 一 个 实例 来 看 一 下 吧 。 具 体 步骤 如 下 所 示 : 


准备 ”预先 创建 两 个 目录 dbr 和 rep， 作 为 捕获 目录 和 重 放 目 录 ， 并 创建 测试 表 。 


create directory dbr as '/alex/dbr'; 
create directory rep as '/alex/rep'; 
create table alex t411 (id number, name varchar2(100)); 


步骤 1 创建 一 个 flashback 的 回 滚 点 ， 作 为 备份 。 


create restore point rp alex dbr guarantee flashback database; 


步骤 2 创建 一 个 过 滤器 ， 只 选择 ALEX 用 户 的 操作 ， 并 开启 捕获 进程 。 在 start_capture 过 程 中 设置 duration 为 null， 表 示 手 工控 制 捕获 进程 的 开启 和 关闭 。 


begin 
Ey workload capture.add filter (fname => 'ALEX FILTER', 
中 加 fattribute => 'USER', 
fvalue => 'ALEX'); 
end; 
begin 
dbms_workload capture.start capture (name => 'ALEX DBR', 
dir => 'DBR', 
duration => null); 
end; 


步骤 3 完成 60 次 insert，10 次 update，10 次 select 如 下 的 操作 。 如 果 1 倍 压力 ，name 字 段 将 显示 为 “alex*“********” (10 个 “*” 号， 标示 10 次 更 新 ) 。 后 面 进行 压力 测试 ， 如 果 3 倍 压力 ， 是 不 是 就 
会 有 30 个 “*” 号 呢 ? 


insert into alex t411 values (1， 'alex'); 
update alex t411 set name=name||'*'; 
select count (*) from alex t411; 


步骤 4 ”关闭 捕获 操作 。 此 时 可 以 导出 捕获 阶段 的 报告 ， 也 可 以 等 到 重 放 后 导出 。 


begin 
dbms_workload capture.finish capture; 

eng; 

select dbms_ workload capture.report (capture id => 1, format => 'HTML') 
from dual; 


步骤 5 ”从 捕获 目录 (dbr) 复制 捕获 文件 到 重 放 目录 (rep) ， 并 回 滚 数据 库 。 


flashback database to restore point rp alex dbr; 
alter database open resetlogs; 


步骤 6 ”处 理 捕获 信息 。 


begin 
dbms_workload replay.Process_capture (capture dir => 'REP'); 
end; 


步骤 7 初始 化 重 放 。 


begin 
dbms_workload replay.initialize replay( 
replay name => 'ALEX REP', 


replay dir => 'REP'); 


步骤 8 重 放 配置 。 这 里 我 们 进行 压力 测试 ， 如 果 不 进行 压力 测试 ，synchronization 设 置 为 true。 


begin 
dbms_workload replay.prepare replay( 
synchronization => false, 
connect time scale => 80, 
think time scale => 0, 
scale up multiplier => 3); 


步骤 9 ”在 OS 上 开启 3 个 wrc 重 放 客 户 端 ， 在 开启 之 前 可 以 进行 一 下 重 放 评 估 。 在 数据 库 开启 重 放 进 程 。 


wrc system/oracle mode=calibrate replaydir=/alex/rep 

nohup wrc system/oracle mode=replay replaydir=/alex/rep dscn off=true & 
nohup wrc system/oracle mode=replay replaydir=/alex/rep dscn off=true & 
nohup wrc system/oracle mode=replay replaydir=/alex/rep dscn off=true & 
begin 

Gbms_workload replay.start replay(); 

end; 


步骤 10 ”导出 对 比 报告 。 


select dbms_ workload replay.report (replay id => 1, format => "HTML') 
from dual; 


Replay Statistics 


DB Time 19.073 seconds 4.259 seconds 
[Average Active Sessions .33 | .06 
|User calls | 3750 | 1250 
(Network Time | 4.514 seconds N/A 
Think Time | 0.096 seconds N/A 


从 对 比 结果 来 看 ， 我 们 的 压力 测试 是 成 功 的 ， 从 各 项 指标 来 看 ， 数 据 库 的 压力 确实 提升 了 。 


再 来 回顾 一 下 步骤 3 的 问题 ， 当 再 查询 alex_t411 表 的 记录 时 ， 我 们 发 现 name 字 段 还 是 只 有 10 个 “*” 号， 而 没有 预期 的 3 倍 压力 的 30 个 “*” 号 。 


SQL> select * from alex 七 4117 
ID NAME 


了] 1 ER 太太 交 太太 淡 六 

2 1 类 大 太太 大 太 大 

3 Bale 大 交 商 太太 闪 
ee 
59 ale 类 六 太太 大 大 太太 
6 1 太太 交 太太 淡 六 
60 rows selected 


是 的 ， 数 据 库 重 放 的 压力 测试 ， 只 是 通过 缩短 会 话 连接 时 间 间隔 和 缩短 SQL 语句 执行 时 间 间 隔 来 实现 增 压 的 ， 重 放 后 的 数据 库 保持 了 与 捕获 后 的 数据 库 的 数据 一 致 。 而 不 是 像 一 些 第 三 方 的 工具 一 样 ， 
将 抓 取 的 TRACE 文件 按照 设置 的 压力 倍数 重 放 ， 如 : TRACE 对 应 10 个 会 话 ， 共 1000 次 INSERT 操 作 ， 那 么 设置 3 倍 压 力 重 放 ， 则 开启 30 个 会 话 ， 共 3000 次 INSERT 操 作 。 


4.6.2 ”强化 数据 库 重 放 特 性 


然而 ，Oracle 数 据 库 一 直 都 是 很 人 性 化 的 ， 已 经 帮 我 们 想到 了 这 样 的 压力 测试 的 形式 。 从 Oracle 11.2.0.2.0 版 本 开始 ， 就 可 以 使 用 强化 的 数据 库 重 放 (Consolidated Database Replay) 特性 来 实现 这 
样 的 功能 。 当 然 ， 在 开始 使 用 之 前 ， 我 们 必须 选择 性 地 给 Oracle 数 据 库 打 上 一 个 OPatch 的 补丁 ， 各 版 本 的 对 应 补丁 如 表 4-3 所 示 。 


表 4-3 ”强化 数据 库 重 放 功 能 补丁 
数据 库 版 本 补丁 号 
11.2.0.2.0 13947480 
11.2.0.3.0 16086826 (已 包含 13947480 补丁 ) 


要 实现 上 述 预 期 效果 的 压力 测试 ， 在 捕获 阶段 和 上 述 步骤 是 没有 区 别 的 ， 也 就 是 说 在 生产 数据 库 进 行 压力 捕获 是 不 用 额外 的 设置 和 操作 的 。 


从 原理 上 来 讲 ， 普 通 的 数据 库 重 放 功 能 为 什么 不 能 实现 预期 的 压力 测试 重 放 呢 ? 因 为 其 只 能 识别 一 个 重 放 目录 ， 如 果 说 我 们 需要 重 放 3 倍 的 压力 ， 我 们 会 准备 3 份 重 放 目 录 和 捕获 文件 ， 但 是 只 有 一 份 能 
被 识别 。 而 强化 的 数据 库 重 放 功 能 可 以 对 所 有 准备 好 的 重 放 目录 和 捕获 文件 进行 分 组 ， 并 设置 调度 程序 进行 整个 分 组 的 重 放 ， 也 就 是 说 我 们 准备 的 3 份 重 放 目录 和 捕获 文件 ， 其 可 以 通过 1 个 分 组 的 调度 同时 
去 重 放 3 份 ， 也 就 达到 了 我 们 预期 的 目的 。 


从 上 述 步骤 5 开始 ， 我 们 开启 一 个 新 的 强化 数据 库 重 放 的 压力 测试 演示 。 


新 步骤 5 ”内 回 数据 库 后， 再 从 捕获 目录 (dbr) 复制 3 份 捕获 文件 到 重 放 目 录 (rep1、rep2、rep3) 。 在 数据 库 新 建 4 个 directory，3 个 分 别 对 应 3 个 重 放 目 录 ， 另 一 个 目录 alex_workload 作 为 重 放 目 
录 的 调度 根 目录 。 


Create or replace directory repl as '/alex/repl'; 
create or replace directory rep2 as '/alex/rep2'; 
Create or replace directory rep3 as '/alex/rep3'; 
create or replace directory alex workload as '/alex'; 


新 步骤 6 ”设置 重 放 根 目录 。 


begin 
dbms_workload replay.set replay directory('ALEX WORKLOAD'); 
end; 


新 步骤 7 ”处 理 重 放 子 目 录 。 


begin 
dbms_workload replay.process capture (capture dir => 'REP1'); 
dbms_workload replay.process_ capture (capture dir => 'REP2'); 
dbms_workload replay.process_ capture (capture dir => 'REP3'); 


end; 
新 步骤 8 ”设置 重 放 调度 作业 。 
begin 
dbms_workload replay.begin replay schedule('ALEX SCHEDULE'); 
end; 


select dbms workload replay.add capture('REP1') from dual; 
select dbms_ workload replay.add capture('REP2') from dual; 
select dbms_ workload replay.add capture('REP3') from dual; 
begin 

dbms_workload replay.end replay_ schedule; 
eng; 


新 步骤 9 ”初始 化 重 放 。 


Tan 


begin 
dbms_workload replay.initialize consolidated replay( 
replay name => 'ALEX REPLAY', 
schedule name => 'ALEX SCHEDULE'); 
end; 


新 步骤 10” 重 放 准 备 配置 。 


begin 
dbms_workload replay.prepare consolidated replay( 
synchronization => 'OBJECT ID'); 
end; 


新 步骤 11 在 OS 上 开启 3 个 wrc 重 放 客 户 端 ， 在 开启 之 前 可 以 进行 一 下 重 放 评 估 。 需 要 注意 的 是 ， 评 估 过 程 是 评估 每 一 个 重 放 子 目 录 ， 重 放 过 程 指定 的 是 重 放 根 目录 。 重 放 wrc 客 户 端 数量 为 : 
rep1+rep2+rep3+1。 在 数据 库 开启 重 放 进程 。 


wrc mode=calibrate replaydir=/alex/repl 
wrc mode=calibrate replaydir=/alex/rep2 
wrc mode=calibrate replaydir=/alex/rep3 
nohup wrc system/oracle mode=replay replaydir=/alex 
nohup wrc system/oracle mode=replay replaydi 
nohup wrc system/oracle mode=replay replaydi 
nohup wrc system/oracle mode=replay replaydir=/alex 
begin 

dbms_workload replay.start consolidated replay; 
end; 


Co 


新 步骤 12 ”导出 对 比 报告 。 


select doms workload replay.report (replay id => 1, format => "HTML' 
from dual; 


强化 数据 库 重 放 实 现 普通 重 放 功 能 的 同时 ， 还 带 来 哪些 不 一 样 呢 ， 我 们 预期 的 结果 是 否 达 成 呢 ? 来 验证 一 下 吧 。 再 次 查询 alex_t411 表 ， 我 们 发 现 表 中 一 共有 180 行 记录 ， 且 name 字 段 有 30 个 “*” 号 ， 
量 放 过 程 进行 了 180 行 记录 的 insert 和 30 次 的 update， 预 期 的 3 倍 压 力 重 放 测试 达成 。 


中 


SQL> select * from alex t411 order by id; 
ID NAME 


了] 1 ee 区 炎 大大 大 炎炎 大 克 炎 克 赤 赤 炎 文 炎 大 炎 大 炎炎 火 大 火 太 火灾 大 大 炎 灾 
了] 忆 ] 区 克 太太 大 炎炎 炎炎 炎炎 灾 克 炎炎 大 赤 炎 炎炎 火灾 炎炎 大 灾 炎 容 大 灾 
了] 忆 ] ee 区 克 太太 大 炎炎 炎炎 炎炎 灾 大 炎炎 大 赤 炎 炎炎 火灾 火灾 天 炎炎 容 大 灾 
2 如 ERK 六 六 大 炎炎 闪光 六 炎 闪 次 六 光 闪 交大 交大 交大 大 炎 交 太 闫 次 六 
2 如 ] EK 六 大 炎炎 次 闪 炎 认 次 六 光 闪 次 交 大 交大 闪闪 炎 交 太 大 次 六 
2 了] ERK 炎 六 灿 交 奕奕 交 类 炎 闪光 区 大奖 次 次 六 奖 六 交大 奖 册 奖 六 闪 


EPE 
EE 
EE 
6 1 EE 汉 六 炎 关 淡淡 闪光 交大 交大 闪闪 六 交 太 闪光 认 炎 大盗 六 次 关 内 
6 1 ee 区 炎 交 克 大 炎 大 炎 太 炎炎 大 克 炎 炎炎 赤 炎 文 克 赤 炎 文 炎 炎炎 天 炎炎 火 太 
人 60 1 ee 区 克 太 炎炎 大 大 火 太 大 炎 赤 灵 大 炎炎 灾 赤 灾 赤 赤 克 炎炎 类 磷 炎炎 赤 炎 大 


180 rows selected 


除 此 之 外 ， 强 化 数据 库 重 放 功 能 还 有 一 个 非常 神奇 的 用 途 ， 就 是 可 以 从 多 个 不 同 平台 、 不 同 版 本 的 Oracle 数 据 库 捕获 数据 库 压 力 ， 生 成 多 个 捕获 子 目录 ， 并 将 这 些 子 目录 集合 到 同一 个 调度 根 目录 下 ， 
在 同一 个 数据 库 进行 压力 重 放 。 具 体操 作 的 方法 与 以 上 压力 测试 的 方法 相同 ， 只 是 捕获 的 子 目录 数据 库 来 源 不 一 样 ， 在 重 放 之 前 需要 remap 一 下 客户 端 连 接 。 


总 体 来 说 ， 数 据 库 重 放 功 能 虽然 也 不 是 尽善尽美 的 ， 但 相 比 之 下 ， 还 是 更 具 应 用 场景 的 ， 它 比较 擅长 于 再 现 全 局 的 数据 库 问题 ， 并 对 应 解决 。 


[由 此 处 的 步骤 号 以 图 4-6 中 的 标号 为 顺序 。 


4.7 ”本 章 小 结 


纵 观 本 章 的 内 容 介绍 ， 我 们 的 目的 都 在 盖 述 一 个 问题 : 如 何 使 得 SQL 语句 具有 最 优 的 执行 计划 ， 并 且 保 证 最 佳 的 执行 效果 。 为 了 达到 这 个 目的 ， 我 们 首先 需要 做 一 些 基 础 性 的 工作 ， 包 括 : 


' 理解 及 合理 配置 CBO 优 化 器 ; 


“ 制定 合理 的 统计 信息 收集 策略 及 备份 策略 。 


完成 了 基础 性 的 工作 后 ， 基 本 上 可 以 输出 一 套 比较 理想 的 执行 计划 ， 但 是 不 保证 最 优 ， 需 要 进一步 干预 ,包括 : 


“ 获取 准确 的 执行 计划 ; 


“ 国 化 优化 的 执行 计划 。 


对 于 一 些 高 并 发 的 系统 ， 小 问题 都 可 能 产生 放大 性 的 影响 ， 我 们 需要 将 工作 做 到 尽 可 能 地 精细 化 一 些 ， 需 要 借助 一 些 工 具 来 模拟 


“ 使 用 SPA 工 具 对 SQL 级 别 和 对 象 级 别 的 变化 进行 性 能 影响 分 析 ; 


“ 使 用 Database Replay 工 具 对 数据 库 级 别 的 变化 进行 压力 测试 和 影响 分 析 。 


' 锁 相 关 问 题 ， 介 绍 Lock、Latch、Mutex 相 关 的 高 并 发 的 解决 案例 。 


: REDO 相 关 问题 ， 以 REDO 为 出 发 点 ， 介 绍 高 并 发 写 的 解决 案例 。 


象 看 本 质 ， 又 是 具有 一 定 的 通 性 的 。 


再 优秀 的 架构 设计 ， 也 不 可 能 保证 杜绝 所 有 高 并 发 问题 ， 出 现 了 问题 ， 就 要 去 解决 问题 。 根 据 业务 需求 和 应 


现 问 题 并 解决 ， 包 括 : 


的 不 同 ， 不 一 样 的 高 并 发 数据 库 系统 可 能 表现 出 的 问题 和 现象 也 是 不 一 样 的 ， 但 是 剖 开 现 


本 章 将 从 实际 的 高 并 发 问题 解决 案例 出 发 ， 介 绍 一 些 Oracle 数 据 库 在 高 并 发 读 写 问题 上 的 解决 方法 与 技巧 。 希 望 在 个 性 的 案例 分 析 过 程 中 ， 能 够 发 掘 出 一 些 共性 的 东西 ， 可 以 作为 解决 类 似 问题 的 参 


考 。 


5.1 ， 锁 相关 问题 


锁 的 概念 对 我 们 来 说 并 不 陌生 ， 在 日 常 的 工作 和 交流 中 ， 锁 都 经 常 出 现 。 比 如 关门 时 ， 需 要 一 个 锁 ， 那 么 陌生 人 就 进 不 去 了 。 再 比如 开车 时 ， 系 上 安全 带 ， 就 可 以 把 


在 Oracle 数 据 库 引 以 为 豪 的 特性 中 ， 锁 的 管理 机 制 可 以 算是 数一数二 的 。 在 一 套 高 并 发 的 数据 库 系 统 中 ， 即 使 现在 还 没有 遇 到 锁 的 问题 ， 迟 早 也 是 要 遇 到 的 ， 这 是 一 个 不 得 不 


题 。 


5.1.1 Lock、Latch、Pin、Mutex 


在 Oracle 数 据 库 中 ， 有 四 种 锁 的 机 制 来 保护 数据 库 对 象 和 


(1) Lock 


Lock 是 我 们 通常 意义 上 所 说 的 锁 ， 在 日 常 应 用 中 ， 我 们 更 多 提 及 的 是 
通过 先进 先 出 (FIFO) 队列 的 方式 进行 控制 ， 


0 共享 内 存 区 域 ， 它 们 分 别 是 : Lock、Latch、Pin 和 Mutex。 


自己 放 在 一 个 受 保护 的 锁 中 。 


面 对 的 且 必 须要 解决 的 问 


力 来 说 ， 效 率 就 不 高 了 。 对 于 一 些 时 效 要 求 高 ， 并 发 要 求 高 的 处 理 ，Oracle 还 给 准备 了 其 他 机 制 的 锁 。 


(2) Latch 


Latch， 通 常 我 们 称 其 为 一 种 轻型 的 锁 ， 其 实 这 并 不 准确 ，Latch 和 Lock 是 两 个 不 一 样 的 概念 。Lock 保 护 的 是 数据 库 对 象 ， 而 Latc 


没有 队列 的 管理 方式 ， 它 是 一 种 随机 争 用 的 管理 


理 能 力 。 在 高 并 发 的 系统 上 ， 也 是 值得 去 更 多 关注 的 。 


(3) Pin 


Pin 可 能 有 些 时 候 不 会 被 认为 是 一 种 锁 的 管理 机 制 ， 但 它 和 Latch 一 样 是 


属于 “ 谁 抢 到 算 谁 的 ”。 


同时 ， 与 Lock 相 比 ，Latch 的 影响 周期 是 非常 短 的 ， 也 正 因为 此 ， 使 用 它 管 理 共享 内 存 


务 锁 ， 也 称 为 队列 锁 ， 它 的 主要 作用 是 保护 数据 库 对 象 ， 保 证 


比较 长 ， 所 不 一 样 的 是 Pin 保 护 的 是 共享 内 存 区 域 。 可 以 说 Pin 更 像 是 一 种 轻型 的 锁 。 


(4) Mutex 


h 保 护 的 是 数据 库 共享 内 存 区 域 。Latch 也 可 分 为 共享 和 排他 两 种 ， 但 其 
区 域 才 显得 更 高 效 ， 能 保证 更 高 的 并 发 处 


务 操作 中 的 数据 一 致 性 ， 可 分 为 共享 锁 和 排他 锁 。 在 管理 上 ， 它 
影响 周期 会 比较 长 ， 也 就 是 说 在 队列 中 等 待 的 时 间 会 比较 长 。Lock 的 这 种 管理 方式 可 以 很 好 地 保证 Oracle 要 求 的 较 高 的 事务 隔离 级 别 ， 但 是 对 于 并 发 处 理 能 


保护 共享 内 存 区 域 的 。Pin 也 可 以 分 为 共享 和 排他 两 种 类 型 ， 其 和 和 Lock 一样 采用 的 是 FIFO 队 列 方式 的 管理 ， 因 而 影响 周期 会 


Mutex 一 般 我 们 可 以 视 为 Latch 的 一 个 “小 兄弟 ”， 这 个 概念 是 在 Oracle 10g 开 始 引进 的 ， 它 不 是 Oracle 的 发 明 ， 而 是 操作 系统 提供 的 一 个 底层 调用 ，Oracle 只 是 利用 它 实现 呈 
掉 部 分 Latch 和 Pin， 以 提高 处 理 效率 。 


Mutex 具 有 两 个 变量 : 持 有 标示 (Holider identifer) 和 3 引 
每 当 会 话 以 共享 方式 持 有 Mutex 时 ， 计 数 会 + 1， 而 释放 时 会 - 1。 如 果 引 | 


相 比 Latch 而 言 ，Mutex 是 一 种 


更 为 轻 量 级 的 锁 ， 使 用 也 


更 灵活 。 


计数 大 于 0， 则 表示 该 内 存 结构 正在 被 Pin 住 。 


“ 一 个 Latch 往 往 需要 保护 大 量 内 存 结构 ， 而 有 了 Mutex 之 后 ， 每 一 个 内 存 结构 都 可 以 有 自己 独立 的 Mutex， 而 不 受 Latch 制 约 ， 原 本 可 能 在 Latch 上 的 并 发 争 用 也 被 较 好 地 分 散 了 。 


行 控制 的 功能 ， 并 蔡 换 


计数 (Reference count) 。 持 有 标示 记录 持 有 Mutex 的 ID， 而 引用 计数 是 一 个 计数 器 ， 记 录 了 当前 正在 以 共享 方式 访问 Mutex 的 数量 。 


“ 虽说 Mutex 数 量 较 Latch 更 多 了 ， 但 是 其 处 理 机 制 更 简单 ， 即 使 数量 多 了 ， 效 率 也 更 高 。 一 个 Latch 的 大 小 近 200 字 节 ， 获 取 一 个 Latch 需 要 近 200 个 指令 ; 而 一 个 Mutex 仅 16 字 节 ， 获 取 一 个 Mutex 也 仅 需 


约 35 个 指令 。 


Mutex 一 定 程度 上 兼容 了 Latch 和 Pin 的 优点 ， 它 的 引进 就 是 为 了 解决 共享 内 存 区 域 的 并 发 处 理 能 力 。 


5.1.2 ”游标 争 用 问题 解决 


游标 (Cursor) 争 用 的 问题 ， 了 


EF 要 表现 出 以 下 五 种 等 待 导 


件 比 较 高 : 


* cursor: Imutex X 


* cursor: mutexS 


“ cursor: pinX 


“ cursor: pinS 


* cursor: pinS wait on 又 


自从 Oracle 10g 开 始 引 入 Mutex 来 蔡 代 library cache pin 操 作 后 ， 以 上 问题 都 集中 表现 在 Mutex 结 构 上 的 争 用 。 也 就 是 说 ， 这 类 事件 的 产生 原因 是 出 现 了 Mutex 的 争 用 。 下 面 通过 一 个 案例 来 介绍 一 下 
解决 cursor: pin S 的 思路 。 


数据 库 主机 CPU 资源 利用 率 间歇 性 冲 高 ， 严 重 时 冲 到 100%， 几 乎 瞬间 又 回落 ， 导 致 DB 响应 变 慢 ， 大 量 会 话 连接 超时 。 在 AWR 报 告 中 ， 看 到 较 高 的 cursor: Pin 等 待 ， 这 是 一 个 频繁 执行 SQL 共享 解析 
时 产生 的 竞争 。 


这 通常 是 由 于 某 些 SQL 以 超 高 频率 的 并 发 执行 导致 的 ， 当 然 也 可 能 与 系统 的 CPU 能 力 不 足 有 关 。 在 本 例 中 ， 在 正常 业务 应 用 压力 下 CPU 利用 率 不 足 20%， 排 除了 硬件 问题 ， 通 过 模拟 确定 了 高 cursor: 
Pin S 等 待 导致 CPU 冲 高 。 


2. 问 题 演示 


同时 开启 两 个 会 话 ， 均 无 限 次 循环 执行 一 句 简单 的 SQL 语句 : select user from dual， 那 么 这 两 个 会 话 将 不 断 产生 相互 间 的 Mutex 争 用 。 


会 话 一 : 


SQL> select a.sid, c.spid 
from (select distinct sid from VSmystat) ay 
VS$Ssession b, 
VS$Sprocess c 
where a.sid = b.sid 
and b.paddr = c.addr; 
SID SPID 
46 25770 
SQL> declare 


ao w 


2 Vv sql varchar2 (200) ; 
3 begin 
4 loop 
5 Vsql := 'select user from dual'; 
6 end loop; 
7 end loop; 
8 end; 
9 4 
会 证 二 


SQL> select a.sid, c.spid 
from (select distinct sid from VS$Smystat) ay 
VS$Ssession b, 
VS$Sprocess c 
where a.sid = b.sid 
and b.paddr = c.addr; 
SID SPID 
156 25768 
SQL> declare 
Vv_ sql varchar2 (200)，; 
begin 
loop 
Vsql := 'select user from dual'; 
end loop; 
end loop; 
end; 


‘ 


ao wN 


加 ooawmmwN 


监控 会 话 : 


任 会 话 一 和 会 话 二 同时 运行 的 过 程 中 ， 监 控 到 两 个 会 话 都 出 现 了 持续 cursor: pin S 的 等 待 ， 因 为 不 是 队列 锁 的 等 待 ，blocking_session 没 有 发 现 阻塞 会 话 ，Oracle 认 为 该 会 话 是 正常 运行 的 。 


SQL> select a.sid, a.event, a.blocking session，b.sql_text 


2 from v$session a, v$sqlarea b 

where a.sid in (46, 156) 

4 and a.sql hash value = b.hash value (+); 

SID EVENT ~ BLOCKING SESSION SQL TEXT 

46 cursor: pin S Select user from dual 
156 cursor: pin S Select user from dual 


对 比 互 斥 会 话 启动 前 和 执行 一 段 时 间 后 的 Mutex 状 态 ， 发 现 Cursor Pin 类 型 的 Mutex 的 SLEEPS 持 续 高 速 增 长 ， 验 证 了 M utex 争 用 的 设想 。 


SQL> select * from VS$Smutex sleep where mutex type='Cursor Pin'; 


MUTEX_TYPE LOCATION SLEEPS WAIT TIME 
Cursor Pin kksLockDelete [KKSCHLPING] 1 8558 0 
Cursor Pin kksfbc [KKSCHLFSP2] 177958 0 
如 图 5-1 所 示 ， 从 操作 系统 的 top 监 控 看 到 ， 区 区 两 个 会 话 将 原本 空闲 的 CPU 资源 ， 一 下 子 冲 高 到 41.9% 的 利用 率 。 


LOAD USER NICE IDLE BLOCK SWAIT 


0.77 41.95 0 .0 地 s = 和 0 . 0% 0 .0% 0 .0 


System Pade Size: 4Kbytes 


emory: 68397520K {21405200K) real, 76277988K {24630340K) virtual, 11716947100K free 


CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME S$WCPU $CPU COMMAND 
16 2? 25770 oracle 241 20 63971M S164K run 4:39 100.27 100.09 oracle 
18 3 25768 oracle 241 20 6398M 5828K run 4:40 100.13 99.96 Oracle 


图 5-1 Mutex 争 用 的 CPU 监控 


3 .解决 思路 


Mutex 管 理 机 制 ， 其 原理 为 在 每 个 子 游标 上 分 配 一 个 地 址 空间 记录 独立 的 Mutex， 当 该 游标 被 共享 执行 时 ， 通 过 对 该 位 进行 + 1 处 理 来 实现 。 虽 然 是 游标 共享 ， 但 是 更 新 Mutex 结 构 的 操作 需要 排他 ， 
当 某 一 个 SQL 被 频繁 共享 执行 时 ， 可 能 就 会 出 现 cursor: pin S 的 等 待 。 更 可 怕 的 是 ， 在 Mutex 的 引用 计数 器 上 等 待 的 这 些 会 话 虽 然 在 Oracle 上 标示 为 SLEEP 状态 ， 但 是 其 在 操作 系统 层面 仍然 占用 了 CPU 的 
时 间 片 ， 并 没有 真正 进入 SLEEP， 也 就 是 说 ， 这 样 的 并 发 争 用 越 高 ，CPU 资 源 的 消耗 也 就 越 高 。 


如 上 例 演示 ， 区 区 两 个 会 话 的 循环 执行 就 造成 了 严重 的 Mutex 争 用 ， 引 起 CPU 的 冲 高 ， 如 果 是 并 发 度 很 高 的 情况 呢 ? 相信 问题 将 会 愈 发 严重 。 该 类 问题 在 实际 生产 应 用 中 也 是 展 见 不 鲜 的 ， 比 如 : 在 表 
的 DML 操 作 的 触发 器 上 ， 触 发 器 的 行为 可 能 非常 单一 ， 如 果 高 并 发 频繁 地 对 该 表 进 行 DML 操 作 ， 就 很 可 能 引发 这 类 问题 。 


要 解决 该 类 问题 ， 其 思路 也 是 非常 简单 的 。 将 频繁 执行 的 SQL 对 应 的 游标 进行 拆 解 ， 分 散 Mutex 的 竞争 ， 如 以 下 SQL 通过 注释 将 同一 条 SQL 分 解 为 10 条 ， 就 分 散 了 竞争 。 


select /*SQL 1*/ user from dual; 
select /*SQL 2*/ user from dual; 
select /*SQL 3*/ user from dual; 
select /*SQL 4*/ user from dual; 
select /*SQL 5*/ user from dual; 
select /*SQL 6*/ user from dual; 
select /*SQL 7*/ user from dual; 
select /*SQL 8*/ user from dual; 
select /*SQL 9*/ user from dual; 
select /*SQL 10*/ user from dual; 


在 正常 的 SQL 优化 工作 中 ， 我 们 通常 的 做 法 是 尽 可 能 地 实现 游标 共享 。 在 本 例 中 ， 我 们 几乎 是 反 其 道 而 行 之 。 这 个 思路 恰恰 又 是 和 Oracle 优 化 锁 机 制 是 一 样 的 ， 尽 可 能 细 粒 度 化 锁 ， 使 用 更 多 的 轻 量 级 
的 锁 来 将 原本 会 在 一 个 点 上 的 锁定 分 散 开 来 ， 虽 然 “ 锁 ” 多 了 ， 但 是 同时 在 一 个 点 出 现 争 用 的 几率 小 了 ， 整 个 数据 库 系统 的 运行 才 更 高 效 了 。 


4. 并 发 模拟 


我 们 需要 先 创建 两 个 存储 过 程 (一 个 是 原始 情况 ， 另 一 个 是 进行 了 Mutex 优 化 后 的 情况 ) 来 模拟 高 并 发 的 实际 场景 ， 然 后 通过 高 并 发 的 调用 来 再 现 争 用 的 问题 。 下 面 结合 SQL 语 句 进行 介绍 。 
(1) 并 发 模拟 实例 代码 


@ 原 始 情况 : 


create or replace procedure test cursor is 
chint number; 
begin 
select mod(sid, 10) + 1 into chint from v$mystat where rownum < 2; 
for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 1000000 loop 
execute immediate 'select user from dual'; 
end loop; 
end test cursor; 


@Mutex 优 化 后 情况 : 


Create or replace procedure test cursor is 
chint number; i 
begin 
select mod(sid, 10) + 1 into chint from v$mystat where rownum < 2; 
for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 1000000 loop 
execute immediate 'select /*SQL' ||to char(chint)|| '*/ user from dual'; 
end loop; | 
end test_ cursor; 


(2) 性 能 分 析 


先 来 对 比 一 下 QPS 和 平均 等 待 时 间 。 如 图 5-2 所 示 ， 曲 线 是 QPS， 对 应 右 侧 纵 坐 标 ; 柱 状 图 是 平均 等 待 时 间 ， 对 应 左 侧 纵 坐 标 ， 横 坐标 是 递增 的 并 发 压力 倍数 ， 从 5 倍 到 100 倍 。 


@QPS 曲 线 : 
原始 情况 的 曲线 较 低 ， 经 过 起 初 短暂 的 上 升 后 ， 出 现 性 能 拐点 ， 突 降 到 10000 左 右 进入 稳定 平台 期 ， 可 见 出 现 了 性 能 问题 。 
优化 后 的 曲线 ， 呈 现 逐 步 上 升 ， 在 较 高 水 平 (150000) 进入 稳定 平台 期 。 从 曲线 对 比 来 看 ， 优 化 效果 非常 明显 。 当 然 本 例 模拟 的 是 一 个 极端 情况 ， 也 是 为 了 使 对 比 效果 更 为 明显 。 


@ 平 均等 待 时 间 柱 状 图 : 


很 显然 柱状 图 较 高 的 是 原始 情况 ， 每 次 的 平均 等 待 约 为 5 毫秒 ， 与 之 相 比 ， 优 化 后 的 等 待 时 间 几乎 可 以 忽略 不 计 。 
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图 5-2 Mutex 争 用 并 发 模拟 QPS 对 比 


观察 测试 过 程 中 的 CPU 使 用 情况 ， 如 图 5-3 所 示 ， 上 图 对 应 是 原始 情况 ， 在 出 现 性 能 拐点 之 前 ，CPU 呈 现 逐 步 上 升 的 趋势 ， 进 入 平台 期 后 ，CPU 持 续 100%， 且 整个 测试 过 程 持 续 了 近 3 个 小 时 才 全 部 完 
成 。 而 下 图 对 应 的 优化 后 的 情况 ，CPU 仅 间隙 性 地 短暂 出 现 80% 使 用 情况 ， 整 个 测试 过 程 不 到 半 个 小 时 就 完成 了 。 


图 5-3 Mutex 争 用 并 发 模拟 CPU 利用 率 对 比 


从 并 发 模拟 的 测试 结果 可 以 看 到 ，Mutex 争 用 解决 了 ，CPU 使 用 率 的 问题 也 解决 了 。 如 图 5-4 所 示 ， 在 AWR 报 告 中 看 到 的 ， 分 散 游 标的 方法 不 会 增加 软 解析 、 硬 解析 及 共享 池 的 碎片 。 当 然 ， 即 使 采 
用 ， 也 不 可 分 散 太 多 的 类 似 游标 ， 需 要 控制 好 划分 的 类 似 游标 的 数量 。 
原 可 况 优化 后 情况 


896 | 7| 引 1.7 |concurrency latch: library cache lock 


| | ae EN [control fle paralel write 村 | 坑 | a 四 
mare [ii om oper | af of 1 
[Buffer Nawait %: | 10000 |Redo Nowait %: 10000 [BufferNowat%: | 10000lRedoNowat%: | 100.00 
Buffer Hit %: | 83.95 [in-memory Sort %: 10000 [Euffer Hi es | 9996 |n-memory Sort %- | 100o 
ay np 0000 [ay 居中 | 95.46 [Sof Parse %: [100.00 
[Execute to Parse %: | 89998 [Latch Hit%: 9787 | ee EC TN 
(Parse CPU io Parss Elapsd %: | % Non-Parse CPU- 100.00 [Parse CPU to Parse Flapsd %- | 5000 |% Non-Parse CPU- | 


图 5-4 Mutex 争 用 并 发 模拟 AWR 对 比 


5.1.3 ”索引 争 用 问题 解决 


我 们 知道 索引 是 一 种 典型 的 数据 库 对 象 ， 且 使 用 频率 非常 高 。 在 并 发 处 理 过 程 中 ， 索 引 的 数据 一 致 性 也 是 通过 Lock 机 制 来 保护 的 。 当 在 索引 结构 上 出 现 频繁 的 DML 操 作 时 ， 很 有 可 能 会 触发 素 引 上 的 队 
列 锁 的 等 待 。 


该 类 问题 虽然 不 会 像 游标 争 用 一 样 ， 导 致 比较 严重 的 系统 问题 ， 但 是 对 于 应 用 系统 来 说 ， 往 往 也 是 致命 的 。 写 入 操作 受阻 ， 拖 累 该 表 上 所 有 业务 应 用 的 正常 使 用 ， 对 于 RAC 环 境 来 说 ， 影 响 将 会 更 加 明 
显 。 


1. 背 景 介绍 


在 一 次 数据 库 健康 检查 报告 中 ， 我 看 到 在 一 个 核心 表 对 应 的 主键 索引 上 出 现 较 高 的 enq: TX-index contention 等 待 ， 由 于 


F 主键 值 是 按照 序列 有 序 44 


上 成 的 ， 大 量 并 发 插入 导致 索引 的 数据 插入 集中 在 索引 


的 最 右 端 ， 最 右 端的 块 频繁 地 发 生 块 分 裂 ， 在 块 分 裂 时 会 产生 排他 锁 ， 其 他 事物 必须 等 待 块 分 裂 完成 才 可 以 继续 后 续 的 操作 ， 从 而 引发 大 量 的 enq: TX-index contention 等 待 ， 导 致 业务 应 用 系统 阻塞 。 


2. 问 题 演示 


索引 争 用 (enq: TX-index contention) 的 问题 在 第 2 章 的 索引 分 裂 部 分 已 经 介绍 过 了 ， 其 是 一 个 与 索引 分 裂 直接 相关 的 等 待 


件 ， 也 是 一 个 仅 由 索引 分 裂 才 会 触发 的 等 待 事件 。 若 一 个 索引 块 上 发 生 


DMIL 操 作 ， 而 这 个 索引 块 正在 被 另外 一 个 事务 分 裂 ， 则 需要 等 待 分 裂 完成 后 才能 修改 上 面 的 数据 ， 此 时 就 会 发 生 “enq: TX-index contention” 等 待 事件 。 因 为 争 用 的 索引 块 更 集中 了 ， 该 等 待 事件 的 发 


生 次 数 也 就 增加 了 。 


这 里 就 不 对 问题 进行 重复 演示 了 。 


3 .解决 思路 


从 解决 思路 上 来 看 ， 该 类 问题 与 游标 争 用 具有 一 定 的 相似 性 。 为 什么 这 么 说 呢 ? 因为 解决 索引 


在 本 例 中 ， 分 散 争 用 就 是 要 分 散 索 引 条 目 插入 的 目标 区 域 ， 使 原本 集中 在 一 个 或 几 个 叶 节点 块 上 的 


以 选择 全 局 哈 希 分 区 索引 。 顾 名 思 义 ， 哈 希 分 区 索引 就 是 将 原本 在 一 个 段 中 存储 的 索引 结构 ， 按 照 哈 希 算法 分 散 到 多 个 分 区 段 中 进行 存储 ， 和 


不 论 是 反 键 索引 还 是 全 局 哈 希 分 区 索引 ， 都 是 以 牺牲 读 取 性 能 来 换取 写 入 性 能 的 做 法 。 写 入 操作 被 分 散 到 多 个 块 ， 避 免 了 写 入 操作 的 争 


可 以 的 ,现在 反而 需要 读 取 多 个 块 ， 索 引 范 围 扫描 是 不 能 并 行 的 ， 效 率 自 然 就 变 得 比较 差 了 。 


在 第 3 章 表 的 高 效 设计 中 ， 我 们 已 经 提 到 ， 这 类 问题 最 好 的 解决 方法 就 是 在 主键 设计 阶段 就 考虑 到 ， 避 免 类 似 争 


= 
内 。 


的 问题 ， 仍 然 需要 分 散 争 用 的 热点 ， 这 似乎 是 所 有 热点 和 


问题 解决 的 共同 思路 。 


插入 操作 分 散 到 更 多 的 叶 节点 块 上 。 在 第 2 章 提 到 的 反 键 索引 是 一 个 不 错 的 选择 ， 同 样 的 思路 ， 我 们 可 
分 区 表 的 概念 是 比较 类 似 的 。 


秆 待 。 当 业务 进行 范围 查询 的 时 候 ， 原 本 读 取 一 两 个 数据 块 就 


的 出 现 。 这 样 我 们 才能 真正 做 到 | 问题 的 主动 预防 ， 而 不 必 在 运 维 阶段 扮演 “救火 队 


跳出 现 有 的 思维 模式 ， 我 们 也 可 以 借助 数据 库 森林 体系 中 的 前 置 内 存 数据 库 来 解决 这 个 问题 ， 并 发 处 理 过 程 可 以 由 内 存 数据 库 来 完成 ， 内 存 数据 库 再 与 Oracle 数 据 库 交 互 ， 实 现 数据 同步 ， 因 为 数据 同 
步 是 批量 操作 ， 自 然 就 规避 了 并 发 压力 的 问题 ， 当 然 这 样 会 造成 一 定 的 数据 延迟 。 内 存 数 据 库 的 内 容 将 在 第 二 部 分 纵横 篇 具体 展开 介绍 。 


4. 并 发 模拟 


我 们 需要 先 创建 一 个 同 构 于 生产 环境 问题 表 的 测试 表 ， 导 入 真实 数据 填充 ， 并 创建 测试 用 序列 ，F 
INTO VALUES 的 操作 。 下 面 结合 SQL 语 句 进行 介绍 。 


@ 创 建 测试 表 : 


模拟 三 种 类 型 索引 场景 的 并 发 插入 操作 。 生 产 环境 实际 插入 行为 也 非常 简单 ， 


纯 的 INSERT 


癌 
徊 


create table alex ind cont (id number, name Varchar2 (200) ，.…) 


@ 创 建 序 列 : 


Create sequence seq alex ind cont 
minvalue 1 本 
maxvalue 99999999999999999999 
start with 1 

increment by 1 

cache 200; 


@ 创 建 普通 索引 : 


create index idx alex ind cont id on alex ind cont (iqd); 


@ 创 建 反 键 索引 : 


create index idx alex ind cont id on alex ind cont (id) reverse; 


@ 创 建 全 局 哈 希 分 区 索引 : 


create index idx alex ind cont on alex ind cont (id) 
global partition by hash (id) 
partitions 8; 


@ 并 发 插入 语句 : 


INSERT INTO ALEX IND CONT VALUES (SEQ ALEX IND CONT.NEXTVAL,.....); 


接 下 来 模拟 并 发 行为 ， 从 100 路 并 发 开始 ， 以 20 的 步 长 量 递 增 ， 直 到 500 路 并 发 。 细 心 的 读者 可 能 


注意 到 了 这 里 的 并 发 度 设置 的 要 比 上 一 个 案例 高 。 确 实 ， 索 引 的 


候 ， 基 本 上 不 会 出 现 太 大 的 问题 ， 只 有 并 发 度 足够 高 才 会 暴露 出 问题 。 至 于 多 少 并 发 度 会 暴露 问题 ， 还 是 取决 于 具体 的 数据 库 环境 和 业务 场景 。 


如 图 5-5 所 示 ， 模 拟 了 三 种 场景 的 TPS 变 化 曲线 和 enq: TX-index contention 事 件 平均 等 待 时 间 变 化 柱状 图 。 


' 场景 1: 使 用 普通 索引 ， 对 应 的 较 低 的 TPS 曲 线 和 较 高 的 平均 等 待 时 间 柱 状 图 ; 


“ 场景 2: 将 普通 索引 改造 成 反 键 索引 ， 对 应 的 是 较 高 且 波动 较 大 的 TPS 曲 线 和 几乎 不 可 见 的 平均 等 待 时 间 柱 状 图 ; 


“ 场景 3: 将 普通 索引 改造 成 全 局 哈 希 分 区 索引 ， 对 应 的 是 较 高 且 较 平稳 的 TPS 曲 线 和 几乎 不 可 见 的 平均 等 待 时 间 柱 状 图 。 


问题 在 即时 并 发 度 不 算 太 高 的 时 
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图 5-5 索引 争 用 并 发 模拟 


可 以 看 到 经 过 索引 改造 后 ， 不 论 是 反 键 索引 还 是 全 局 哈 希 分 区 索引 ， 较 之 普通 索引 ， 其 TPS 处 理 能 力 都 提升 了 4 倍 左右 。 而 这 4 倍 的 性 能 提升 ， 不 是 节省 了 MO、CPU 或 内 存 开销 所 带 来 的 ， 而 是 消除 了 
enq: TX-index contention 等 待 事件 所 带 来 的 ， 因 此 该 事件 的 平均 等 待 时 间 几 乎 不 可 见 了 。 


再 来 分 析 一 下 单位 时 间 内 的 AWR 报 告 情况 。 如 表 5-1 所 示 ， 在 Top5 的 等 待 事件 中 ， 在 改造 后 的 索引 测试 场景 中 ，enq: TX-index contention 被 消除 了 。 但 是 ， 在 提高 效率 的 同时 ， 次 生出 序列 上 的 争 
用 enq: SQ-contention， 并 且 由 于 事务 提交 更 频繁 了 ， 引 发 了 log file sync 的 等 待 。 这 是 在 提醒 我 们 在 对 一 套 高 并 发 的 数据 库 系 统 调 优 时 ， 需 要 做 到 一 定 的 优化 平衡 。 换 而 言 之 ， 在 问题 点 被 优化 后 ， 次 生 
出 来 的 问题 是 否 能 够 接受 ， 如 果 不 能 就 不 要 优化 得 太 过 ， 有 些 问 题 是 架构 设计 的 失误 造成 的 ， 靠 后 期 的 优化 是 很 难 完 美 解决 的 ， 往 往 会 导致 补 上 一 个 洞 又 出 现 另 一 个 洞 要 去 补 ，DBA 也 就 成 功 地 成 为 了 “ 救 
火 队 员 ”。 


表 5-1 索引 争 用 AWR 报 告 之 Top5 等 待 事件 对 比 


Ts vg Wantrns) | Toral Cal Time 
endq: TX - index contention 1 982 018 29 119 352 
buffer busy waits 2 167 712 24 606 29.7 


Normal index 1205842 | 21720 | 18 | 26.3 
logfilesyne | 120096 | 504 | 4 | 562 
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Reverse Index | latch: cache buffers chains 392 511 
log file switch 11 342 49 


CN 
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nn 
Co 


log file sync 2 465 789 44 901 
Global hash 
ee latch: cache buffers chains 401 021 9712 
partition index 
33 002 人 


关注 完整 体 的 数据 库 状 态 后 ， 再 来 关注 一 下 问题 点 的 情况 (因为 测试 库 没有 其 他 应 用 ， 整 体 数据 库 情况 基本 上 也 可 以 反映 个 体 情况 ) 。 如 表 5-2 所 示 ， 在 问题 索引 段 上 的 行 锁 争 用 和 ITL 争 用 都 明显 下 降 
了 ， 热 点 分 散 的 预期 达成 了 。 
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表 5-2 索引 争 用 AWR 报 告 之 索引 段 争 用 对 比 


Row Lock 


如 表 5-3 所 示 ， 在 Top5 的 等 待 事件 对 比 中 ， 已 经 看 到 次 生 问题 的 出 现 ， 插 入 效率 提高 了 ， 在 MO 方面 的 压力 自然 也 就 加 大 了 ， 需 要 更 多 关注 MO 压 力 是 否 可 以 接受 。 


% of Capture 
95.51 


Normal index 
Reverse index IDX ALEX IND CONT ID 


Global hash partition index 


表 5-3 索引 争 用 AWR 报 告 之 I/O 效 率 对 比 


Type Tablespace Av Reads/s Av Writes/s Av Buf Wt(ms) 


Normal index 0 | 12.34 
Reverse index DBADATA | 0 | 6.01 
Global hash partition index ”0o | 5.03 


此 类 问题 最 好 是 在 设计 阶段 就 考虑 到 并 有 效 解决 。 如 果 在 运 维 阶段 去 解决 ， 需 要 考虑 到 次 生 的 问题 。 在 本 例 中 如 果 不 能 在 设计 阶段 解决 ， 需 要 尽 可 能 使 用 插入 操作 的 批量 提交 蔡 换 高 并 发 离散 性 提交 ， 
避免 次 生出 log file sync 的 问题 。 在 5.2.4 中 ， 我 们 会 再 深入 剖析 一 下 该 等 待 事件 。 


5.1.4 LOB 争 用 问题 解决 


关于 LOB 字 段 的 使 用 ， 在 第 3 章 高 效 表 的 设计 中 已 经 做 了 比较 深入 的 剖析 。LOB 字 段 出 现 高 并 发 争 用 的 根本 原因 是 通过 LOB INDEX 结 构 进行 CHUNKS 寻 址 的 争 用 ， 以 及 开辟 空闲 空间 ， 分 配 新 的 
CHUNKS 的 


对 于 LOB 字 段 的 使 用 ， 更 多 的 场景 应 该 是 用 于 那些 VARCHAR2 字 段 存 储 不 下 ， 而 又 不 方便 使 用 文件 系统 存储 的 比较 小 的 文件 ， 特 别 是 一 些 较 小 的 文本 文件 (大 小 在 几 十 KB 到 几 百 KB 的 范围 内 ) ， 如 果 
使 用 文件 系统 去 存储 ， 太 多 的 小 文件 势必 造成 管理 成 本 的 提高 ， 而 且 系统 对 这 些 文件 的 读 写成 本 也 将 提高 。 比 较 尴 众 的 是 用 VARCHAR2 又 存储 不 下 ， 有 的 设计 者 甚至 退 而 求 其 次 ， 选 择 通过 多 个 VARCHAR2 
字段 来 拼接 出 一 个 大 VARCHAR2 的 存储 。 


出 


在 VARCHAR2 字 段 上 来 看 ，Oracle 数 据 库 似乎 不 如 其 他 数据 库 那么 好 用 ， 但 是 如 果 能 较 好 地 轰 驭 LOB 字 段 ， 就 会 发 现 这些 顾 虑 是 多 余 的 。 


在 某 互联 网 应 用 系统 的 数据 库 中 ， 某 一 业务 核心 表 采 用 了 LOB 大 对 象 类 型 字段 。 由 于 Oracle 本 身 操作 效率 不 高 ， 在 并 发 插入 操作 突 增 的 情况 下 ， 出 现 资源 争 用 等 待 (enq: HW-contention) ， 数 据 库 
无 法 及 时 将 请 求 返回 给 应 用 ， 导 致 应 用 出 现 堵塞 。 


基于 以 上 背景 ， 需 要 提高 LOB 字 段 的 读 写 吞 吐 量 ,特别 是 并 发 写 的 吞吐 量 。 如 何 提升 LOB 字 段 高 并 发 处 理性 能 呢 ? 还 是 需要 从 LOB 字 段 的 存储 本 质 入 手 。 


2. 问 题 演示 


生产 数据 库 中 的 LOB 字 段 应 用 主要 以 30KB~40KB 的 文本 文件 的 形式 存储 和 更 新 ， 选 择 40KB 大 小 的 文本 文件 作为 测试 对 象 ， 自 定义 一 个 标准 化 事务 : 1 行 插入 + 1 行 读 取 + 1 行 更 新 + 1 行 读 取 ， 并 且 通 过 
如 下 的 一 个 存储 过 程 来 实现 该 事务 的 执行 。 对 比 BasicFile 和 SecureFile 的 LOB 字 段 在 默认 存储 选项 (NOCACHE + LOGGING) 下 ，500 路 并 行 50 次 循环 事务 的 性 能 分 析 。 


CREATE OR REPLACE PROCEDURE test blob IS 


pid NUMBER, 

b BLOB; 

p file VARCHAR2 (20) := 'alex.txt'; 

src loc BFILE := BFILENAME ('CWD', p file); 
amount INTEGER := 4000; 四 

1 blob BLOB; 


1 blob len INTEGER; 
lbuffer RAW(32767); 
1 amount BINARY INTEGER := 32767; 


1 pos INTEGER := 1; 
BEGIN 
select sid || lpad(round (dbms random.value (1, 999999999)), 9, 0) 
into pid 


from VS$Smystat 
where rownum < 2; 
-- 插入 一 行 记录 
INSERT INTO resumes 
VALUES 
(pid, p_file, EMPTY BLOB()) 
RETURNING resume INTO b; 
DBMS_LOB.OPEN (src_loc, DBMS LOB.LOB READONLY); 
amount := DBMS LOB. GETLENGTH (src loc); 
DBMS LOB.LOADFROMFILE (b, src om amount); 
DBMS LOB. CLOSE (src_loc); 
COMMIT; 
-- 查询 刚 插入 的 记录 
select resume into 1 blob from resumes where id = pid; 
1 blob len := DBMS LOB.GETLENGTH (1 ._blob); 
WHILE I pos < 1 blob len LOOP 
DBMS_LOB. RERAD (1 ._blob, 1 amount, 1 pos, 1 buffer); 


1 pos := 1 pos + 1 amount; 
END LOOP; 
=-- 更 新 插入 的 LOB 字 段 


UPDATE resumes 
SET RESUME = EMPTY BLOB() 
WHERE id = pid 加 
RETURNING resume INTO b; 
DBMS_LOB.OPEN (src_loc, DBMS_ LOB.LOB READONLY); 
amount := DBMS LOB. GETLENGTH (src _ 1oc) 7 
DBMS LOB.LOADFROMFILE (b, src eee amount); 
DBMS LOB. CLOSE (src_loc); 
COMMIT; 
-- 再 次 查询 
select resume into 1 blob from resumes where id = pid; 
1 blob len := DBMS LOB.GETLENGTH (1 ._blob); 
WHILE I pos < 1 blob len LOOP 
DBMS_LOB. READ(1 1 plob, 1 . amount, 1 pos, 1 buffer); 
1 pos := 1 pos + 1 amount; 
END LOOP; 
END; 


测试 过 程 将 进行 以 下 AWR 报 告 的 对 比分 析 。 如 表 5-4 所 示 ， 在 Top5 的 等 待 事件 中 ， 可 以 看 到 BasicFile 的 85.01% 等 待 时 间 (总 计 64630 秒 ) 在 等 待 写 入 LOB， 而 实际 LOB 的 写 入 和 读 取 总 量 是 一 样 的 ， 可 
见 SecureFile 在 高 并 发 情况 下 的 处 理 能 力 更 强 。 另 外 ， 值 得 关注 的 是 BasicFile 中 的 “enq: HW-contention” 等 待 事件 ， 在 SecureFile 中 并 未 出 现 。 


表 5-4 LOB 争 用 AWR 报 告 之 Top5 等 待 事件 对 比 


Type Event Wait Class 
a 0 : User LO 

53 125 ， 2 -22 Configuration 

Concurrency 


log file sync 302 Commit 


如 表 5-5 所 示 ， 对 于 LOB INDEX， 在 BasicFile 中 出 现 了 较 多 的 逻辑 读 和 一 定 程度 上 的 行 级 锁 等 待 ， 同 样 的 问题 在 SecureFile 中 并 未 出 现 。 


表 5-5 LOB 争 用 AWR 报 告 之 LOB 段 对 比 


SYS _IL0000262453C0000333 
SYS IL0000262453C000035$5$ 


Row Lock Waits 


BasicFile 


SecureFile 


3. 解 决 思路 


在 第 3 章 中 ， 我 们 介绍 了 SecureFile 的 存储 方式 可 以 有 效 地 替代 BasicFile 的 存储 方式 ， 用 来 解决 高 并 发 争 用 的 问题 ， 主 要 介绍 了 两 个 方面 存储 特性 的 优化 : 


“可 变 大 小 的 CHUNKS; 


“ 对 于 行 外 存储 的 LOB 字 段 ， 规 避 通 过 LOB INDEX 结 构 进 行 CHUNKS 寻 址 的 方式 。 


在 本 例 中 ，BasicFile 方 式 存储 的 LOB 字 段 在 高 并 发 插入 数据 的 时 候 ， 频 繁 出 现 enq: HW-contention 等 待 ， 可 见 在 空闲 空间 分 配 的 时 候 ， 出 现 了 一 些 争 用 的 问题 ， 那 么 来 看 一 下 LOB 字 段 的 空闲 空间 是 
如 何 管理 和 分 配 的 吧 。 


BasicFile 方 式 存储 的 LOB 字 段 ， 其 空间 使 用 情况 信息 是 保存 在 LOB 段 和 LOB INDEX 结 构 中 的 ， 在 LOB 段 发 生 插入 和 更 新 的 时 候 ， 首 先 从 LOB 段 的 管理 区 搜索 空闲 空间 ， 如 果 没 有 ， 则 访问 LOB INDEX 结 
构 。 如 果 不 存 在 可 以 释放 的 空间 ， 再 将 HWM 升 高 ， 扩 大 LOB 段 大 小 。BasicFile 的 LOB 在 搜索 空闲 空间 时 ， 还 是 有 可 能 会 去 扫描 LOB INDEX 的 ， 进 一 步 增加 了 LOB INDEX 的 争 用 几率 。 问 题 再 一 次 集中 到 了 
LOB INDEX 结 构 上 。 


对 于 以 SecureFile 方 式 存储 的 LOB 字 段 ， 其 空闲 空间 的 管理 被 前 置 入 共享 池内 存 区 域 ， 空 闲 空间 和 CHUNKS 的 分 配 都 在 内 存 中 完成 ， 因 此 效率 比 访问 LOB INDEX 高 了 不 只 一 个 数量 级 。 这 些 信息 由 后 台 
进程 SMCO/Wnnn 来 定期 更 新 。SMCO/Wnnn 监 视 SecureFile 的 LOB 段 的 使 用 情况 ， 根 据 需 要 保证 空闲 空间 的 供应 。 


由 此 可 见 ， 要 解决 enq: HW-contention 等 待 的 问题 ， 也 还 是 需要 解决 LOB INDEX 结 构 访问 
间 管 理 方式 。 


问题。 当然， 如 果 使 用 SecureFile 方 式 来 替代 ， 我 们 可 以 得 到 另 一 个 特性 的 优化 : 快速 高 效 的 空闲 空 


在 Oracle 10g 库 中 ， 建 议 在 有 可 能 发 生 高 并 发 插入 的 情况 下 ， 尽 量 避 免 使 用 LOB 字 段 。 不 得 不 使 用 的 时 候 ， 可 以 考虑 在 Oracle 10.2.0.3 + Patch63766915 及 以 上 版 本 设置 1024 级 别 的 EVENT 
44951 (set event 44951 up to 1024) ， 修 改 CHUNKS 从 1 到 1024， 增 加 在 空闲 空间 扩展 时 进行 CHUNKS 的 预 分 配 的 数量 。 该 方法 为 Oracle 推 荐 的 优化 方法 ， 但 是 在 实际 使 用 中 效果 并 不 是 很 理想 。 


在 Oracle 119 库 中 ， 建 议 使 用 SecureFile 方 式 存储 LOB 字 段 ， 以 应 对 高 并 发 处 理 及 优化 存储 的 问题 。 其 可 变 CHUNKS 设 置 和 内 存 管 理 空闲 空间 分 配 的 特性 ， 可 天 然 解决 以 上 等 待 事件 问题 。 


4. 并 发 模拟 


在 开始 模拟 之 前 ， 先 来 介绍 一 下 与 LOB 字 段 性 能 密切 相关 的 两 组 存储 参数 : LOGGING/NOLOGGING/FILESYSTEM_LIKE_LOGGING 参 数 决 定 REDO 日 志 记 录 情 况 ; NOCACHE/CACHE 参 数 决定 SGA 
是 否 对 LOB 字 段 进行 缓存 。 


"LOGGING: 在 LOB 字 段 进 行 DML 操 作 时 会 写 入 REDO 上 日 志文 件 。 (上 默认 值 ) 

:NOLOGGING: 在 LOB 字 段 进行 DML 操作 时 不 写 入 REDO LOG 文 件 。 

:FILESYSTEM_LIKE_ LOGGING: 只 有 SecureFile 才 有 ， 只 记录 LOB 的 基本 数据 到 REDO 上 日志， 确保 数据 库 能 完整 恢复 。 
: NOCACHE: LOB 数 据 不 缓存 在 SGA 内 存 区 域 (默认 值 ) 。 


“ CACHE: LOB 数 据 缓存 在 SGA 内 存 区 域 。 


在 默认 的 设置 中 ， 是 NOCACHE 和 LOGGING 的 组 合 ， 这 也 是 较 大 限度 地 保证 数据 库 可 用 性 和 数据 一 致 性 的 较 好 做 法 。 


在 高 并 发 测试 中 尽 可 能 地 模拟 实际 应 用 特征 ， 以 40KB 大 小 的 文本 文件 作为 测试 对 象 ， 同 样 选择 以 上 自 定义 的 标准 化 事务 ， 以 100 路 、200 路 、300 路 、500 路 、1000 路 的 并 行 压力 分 别 进 行 50 次 事务 循 
环 ， 测 试 BasicFile 和 SecureFile 在 四 种 不 同 存储 参数 设置 下 的 多 线程 事务 处 理 能 力 。 如 图 5-6 所 示 ， 在 NOCACHE 情 况 下 SecureFile 优 势 明 显 ， 与 在 CACHE 情 况 下 相差 不 大 。 虽 然 NOLOGGING 模 式 能 带 来 
一 定 程度 TPS 的 提升 ， 但 现在 的 Oracle 数 据 库 基本 上 都 有 灾 备 环境 ， 因 此 选择 LOGGING 模 式 是 比较 明智 的 ， 牺 牲 掉 这 一 点 性 能 也 是 值得 的 。 
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图 5-6 LOB 争 用 之 存储 参数 测试 


在 CACHE 模 式 下 为 什么 差异 不 大 呢 ? 因为 目标 LOB 数 据 都 被 SGA 缓 存 了 ， 这 样 的 做 法 无 形 中 会 给 SGA 制 造 很 大 的 麻烦 ， 因 为 LOB 字 段 的 体积 一 般 都 是 比较 大 的 。 如 果 说 NOLOGGING 模 式 是 可 以 考虑 
的 ， 那 么 CACHE 模 式 是 必须 要 禁止 的 。 需 要 提 一 下 的 是 ，BasicFile 是 不 支持 CACHE 和 NOLOGGING 的 组 合 的 。 


相 比 BasicFile 来 说 ，SecureFile 在 功能 上 也 做 了 很 大 的 扩展 ， 与 高 并 发 性 能 直接 相关 的 两 个 特性 就 是 去 重 LOB 和 压缩 LOB。 


“ 去 重 LOB (DEDUPLICATE 选 项 ) ， 在 表 或 分 区 删除 重复 的 数据 ， 可 以 将 原本 多 份 重复 存储 的 数据 简化 为 单 份 的 存储 ， 实 现 重复 数据 的 删除 。 


“ 压缩 LOB (COMPRESS 选 项 ) ， 在 表 或 分 区 对 LOB 数 据 的 压缩 ， 在 压缩 过 程 中 可 能 会 增加 一 定 的 系统 开销 。 


以 上 两 种 方法 都 可 以 起 到 表 空间 节省 的 作用 ， 对 于 LOB 字 段 的 优化 存储 有 着 积极 的 作用 。 下 面 我 们 再 来 考察 一 下 这 两 种 功能 对 高 并 发 应 用 是 否 有 益 呢 ? 


如 图 5-7 所 示 ， 是 一 张 原始 LOB、 去 重 LOB、 压 缩 LOB 的 并 发 压力 测试 的 TPS 曲 线 对 比 图 。 可 以 看 到 ， 在 面 对 并 发 处 理 压 力 的 时 候 ， 压 缩 LOB 有 非常 明显 的 优势 ， 而 去 重 LOB 则 处 于 明显 的 劣势 。 其 中 的 
原因 在 第 3 章 我 们 也 提 到 过 ， 因 为 LOB 启 用 去 重 还 是 会 通过 LOB INDEX 进 行 寻 址 ， 和 BasicFile 没 有 太 大 区 别 ， 就 形 失 了 SecureFile 的 优势 。 
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图 5-7 LOB 争 用 之 去 重 压缩 对 比 
再 来 看 一 下 原始 LOB、 去 重 LOB、 压 缩 LOB 三 者 其 他 性 能 的 指标 吧 ， 如 表 5-6 所 示 。 


表 5-6 原始 LOB、 压 缩 LOB、 去 重 LOB 性 能 对 比 


CPU 消耗 存储 空间 
了 
RA 


“ 存储 空间 方面 ， 去 重 LOB 是 最 好 的 ， 压 缩 LOB 虽 然 不 如 去 重 LOB， 但 较 之 原始 LOB 也 是 有 几 倍 的 空间 节省 。 


首要 等 待 事件 
log file sync (51% 占 比 ) 


DB CPU (45% 占 比 ) 


参数 选项 
原始 LOB 
压缩 LOB 


enq: TX-row lock contention ( 75% 占 比 ) 


“ 逻辑 读 和 物理 读 的 情况 也 基本 上 是 其 空间 使 用 情况 的 反映 。 
“CPU 消耗 方面 ， 压 缩 和 去 重 比 原始 要 有 所 上 升 ， 因 为 在 存储 和 读 取 过 程 中 都 需要 进行 额外 的 计算 ， 这 部 分 额外 开销 也 是 可 以 预期 到 的 ， 从 本 例 的 消耗 度 来 看 ， 还 是 可 以 接受 的 。 


' 等 待 事件 方面 ， 三 者 出 现 了 不 一 样 的 情况 ， 原 始 LOB 因 为 REDO 写 入 量 比较 大 ， 造 成 了 LGWR 进 程 压力 ， 压 缩 LOB 和 去 重 LOB 则 不 存在 ,但 是 去 重 LOB 因 为 采用 了 LOB INDEX 结 构 ， 出 现 较 高 的 行 锁 


综合 上 述 情况 ， 面 对 高 并 发 的 LOB 字 段 使 用 ， 去 重 LOB 虽 然 能 带 来 存储 空间 的 节省 ， 但 是 会 出 现 更 为 严重 的 LOB INDEX 争 用 ， 不 推荐 使 用 。 而 压缩 LOB 平 衡 了 存储 空间 和 TPS 处 理 的 优势 ， 在 合理 评估 


好 CPU 开销 的 基础 上 ， 是 可 以 有 效 提高 并 发 处 理 能 力 的 。 


值得 再 提 一 下 的 是 ， 压 缩 LOB 较 之 原始 LOB 在 并 发 处 理 上 的 优势 ， 在 于 其 写 入 性 能 的 优势 ， 而 在 读 取 方 面 ， 其 优势 并 不 明显 。 


5.1.5 “全 表 锁 问题 解决 


“SELECT*FROM TABLE FOR UPDATE” ， 这 是 个 很 无 移 很 低级 的 问题 ， 看 似 不 应 该 拿 出 来 讨论 的 。 然 而 ， 在 实际 应 用 中 ， 我 不 


贵 是 : “业务 逻辑 就 是 这 样 的 ， 不 这 样 写 不 行 。” 
我 们 说 没有 什么 是 不 这 么 写 就 不 行 的 ， 否 则 就 是 设计 出 了 问题 。 


1. 问 题 演示 


止 一 次 地 在 一 些 核心 系统 上 看 到 这 样 的 SQL 写法 ， 沟 通 下 来 ， 得 到 的 反 


这 个 问题 的 演示 也 很 简单 ， 我 们 开启 5 个 会 话 ， 一 个 〈SID = 145) 模拟 锁 的 持 有 会 话 ， 另 外 四 个 模拟 锁 的 等 待 会 话 


锁 持 有 会 话 (SID = 145) 执行 如 下 SQL 语句 : 


SQL> select * from alex t501 for update; 


其 他 四 个 会 话 均 进 行 单行 更 新 ， 此 时 可 以 观察 到 会 话 145 在 进行 空 等 待 ， 而 其 他 四 个 会 话 均 被 其 阻塞 了 ， 均 持 有 “enq: TX-row lock contention” 的 等 待 事件 。 


SQL> select sid, event, blocking session 
ed from v$session 
5 where sid in (145, 168, 201, 182, 191) 
4 order by sid; 
SID EVENT BLOCKING SESSION 


145 SQL*Net message from client 


168 enq: TX - row lock contention 145 
182 eng: TX - row lock contention 145 
191 enq: TX - row lock contention 145 
201 enq: TX - row lock contention 145 


再 看 一 下 锁 的 实际 持 有 状态 ， 对 于 会 话 145 来 说 ， 在 表 alex_t501 (object id=76657) 上 虽然 只 是 持 有 行 级 的 排他 锁 ， 但 不 幸 的 是 ， 它 对 所 有 行 都 进行 了 排他 ， 也 就 相当 于 是 表 级 的 排他 锁 了 ， 在 
话 完成 事务 提交 或 回 退 之 前 ， 该 表 上 所 有 DML 操 作 都 会 出 现 阻 塞 。 对 于 一 套 并 发 度 较 高 的 数据 库 来 说 ， 很 容易 就 会 出 现 “ 壮 观 ”的 阻塞 场面 。 


阔 


SQL> select sid, type, lmode, block, igl 
本 from v$lock 


3 where sid in (145, 168, 201, 182, 191) 

4 and type in ('TM', 'TX') 

5 order by type, sid; 
SID TYPE LMODE BLOCK ID1 
145 TM 3 0 76657 
168 T™ 3 0 76657 
182 TM 3 0 76657 
191 TM 3 0 76657 
201 TM 3 0 76657 
145 TX 6 1 3932191 
168 TX 0 0 3932191 
182 Tx 0 0 3932191 
191 Tx 0 0 3932191 
201 TX 0 0 3932191 


如 果 出 现 大 量 会 话 被 阻塞 ， 一 方面 业务 应 用 会 受到 影响 ， 另 一 方面 系统 会 消耗 大 量 不 必要 的 CPU_TIME， 拖 累 整个 数据 库 。 也 许 有 人 会 说 : “我 只 是 锁定 很 短 的 时 间 ， 而 且 是 非 关键 表 。” 是 的 ， 也 许 


现在 是 这 样 的 ， 但 是 万 变 的 需要 和 业务 是 不 会 理会 这 一 点 的 ， 埋 下 这 个 地 雷 迟 早 是 要 吃苦 头 的 。 即 使 不 是 高 并 发 的 应 


2. 解 决 思路 


， 也 是 要 杜绝 这 类 问题 的 。 


这 类 问题 的 解决 思路 非常 简单 ， 概 括 起 来 就 是 一 句 话 : 修改 业务 逻辑 ， 改 写 SQL 语 句 。 不 是 所 有 问题 都 可 以 从 数据 库 层面 入 手 解决 ， 甚 至 可 以 说 大 部 分 的 问题 都 是 因为 前 端 业务 应 用 写 得 太 差 而 导致 


的 。 对 于 一 套 高 并 发 的 数据 库 系 统 ， 在 上 线 初 期 一 般 是 不 会 预期 到 太 高 的 并 发 业务 的 ， 类 似 的 一 些 “ 地 雷 ” 


5.2 REDO 相关 问题 


就 会 在 无 意识 的 情况 下 被 坦 


下 ， 数 据 库 架构 师 需 要 更 进一步 深入 到 业务 逻辑 中 去 。 


说 起 高 并 发 ， 更 多 的 人 会 联想 到 读 的 高 并 发 ， 可 能 是 因为 这 个 问题 最 初 是 那些 读 写 比 例 非 常 高 的 数据 库 应 用 提出 来 的 ， 但 这 并 不 意味 着 可 以 忽视 写 的 高 并 发 ， 以 及 由 于 大 量 并 发 写 所 带 来 的 次 生 问题 。 
对 于 一 些 传统 业务 应 用 来 说， 数据 库 的 读 写 比 往往 不 会 那么 高 ， 而 且 读 的 高 并 发 和 写 的 高 并 发 往往 是 耦合 在 一 起 同时 出 现 的 。 接 下 来 我 们 就 要 围绕 在 REDO 日 志方 面 ， 展 开 几 个 案例 的 介绍 。 


5.2.1 ”REDO 块 的 大 小 


数据 块 大 小 的 概念 ， 想 必 大 家 再 熟悉 不 过 了 ， 而 REDO 块 大 小 ， 可 能 不 是 所 有 人 都 关心 过 的 。 我 们 知道 对 于 Oracle 数 据 库 来 说 ， 数 据 块 大 小 是 可 以 选择 的 ， 而 且 这 种 选择 关系 到 数据 库 |/O 性 能 。 那 
么 ，REDO 块 呢 ? 


Oracle 数 据 库 在 写 脏 数据 块 之 前 ,会 先 写 REDO 块 ， 数 据 块 和 REDO 块 在 SGA 共 享 内 存 区 域内 都 是 有 其 专属 的 缓存 区 的 ， 并 且 都 是 通过 后 台 进 程 完成 内 存 和 文件 的 交互 。REDO 块 的 大 小 是 否 也 会 关系 到 
I/O 性 能 呢 ? 


先 来 认识 一 下 REDO 块 的 概念 吧 。REDO 日 志 的 存储 和 数据 的 存储 是 一 样 的， 逻辑 上 的 最 小 存储 单元 都 是 块 (Block) ，MO 交 互 都 是 以 块 作为 最 小 单位 来 进行 传输 的 。 所 不 一 样 的 是 ， 数 据 块 是 可 以 
义 的 ， 而 REDO 块 是 不 可 以 的 ， 其 大 小 取决 于 操作 系统 的 最 小 MO 单元 ， 部 分 操作 系统 取决 于 操作 系统 的 最 小 文件 系统 MO 单元 。 一 些 主流 操作 系统 对 应 的 REDO 块 大 小 如 表 5-7 所 示 。 


装 


表 5-7 REDO 块 大 小 


REDO 块 大 小 操作 系统 
512 字 贡 Solaris, AIX, Windows NT/2000, Linux, OpenVMS, Unix Ware 
1024 字 节 HP-UX, Tru64 Unix 
2048 字 贡 SCO Unix, Reliant Unix 
4096 字 市 MYVS, MPE/ix 


对 于 Oracle 数 据 库 的 REDO 块 大 小 ， 可 以 通过 如 下 查询 直接 获取 。 在 Linux 平 台 操 作 系 统 上 ，REDO 块 的 大 小 显示 为 512 字 节 . 


SQL> select a.platform name plantform, b.redosize 

帝 from VS$database ay 

算 (select max(lebsz) redosize from sys.x$kccle) b; 
PLANTFORM REDOSIZE 


Linux x86 64-bit S12 


接 下 来 ， 我 们 以 两 个 不 同 大 小 REDO 块 的 操作 系统 (Solaris: 512 字 节 ，HP-UX: 1024 字 节 ) 进行 对 比 ， 看 一 下 I/O 性 能 是 否 与 之 有 关联 。 创 建 一 个 测试 表 alex_t502， 插 入 100 万 行 记录 到 其 中 ， 考 察 这 
个 过 程 的 REDO 相 关 信 息 。 下 面 结合 具体 SQL 语句 进行 介绍 。 


@ 创 建 测试 表 : 


create table alex t502 (tabl col number); 


@ 插 入 数据 : 


begin 
for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 1000000 loop 
insert into alex t502 values (i); 
end loop; 
commit; 
end; 


@ 监 控 REDO 信 息 : 


select b.NAME, a.VALUE 
from v$sysstat a, v$statname Pb 
where b.name in ('redo write time', 'redo log space requests', 
'redo 1og space wait time', 'messages sent', 
'redo entries', 'redo size', 'redo synch writes', 
'redo wastage', 'redo writes', 'redo blocks written') 
and a.STATISTIC# = b.STATISTIC#; 


在 Oracle 层 面 捕捉 到 的 一 些 信息 如 表 5-8 所 示 ，Solaris 的 redo size 和 redo wastage 都 有 优势 ， 但 是 REDO 的 写 入 次 数 和 块 数 反而 更 多 了 ，REDO 的 写 入 时 间 更 长 ， 后 台 的 message sent 更 多 。 


表 5-8 Solaris 与 HP-UX 的 REDO 对 比 


redo synch writes | 全 redo blocks written 300 614 
redo entries redo write time 320 
redo wastage redo log space wait time 0 


同时 ,我们 可 以 依据 测试 的 数据 推断 出 REDO 块 的 计算 公式 如 下 (16 字 节 为 REDO 块 头 的 大 小 ) : 


redo log block size = 16 + (redo size + redo wastage) / redo blocks written 


其 结果 基本 和 X$ 表 查询 值 是 一 致 的 : 


* HP-UX: redo log block size=16+ (265153640+139096) /263260 全 1024 


* Solaris: redo log block size=16+ (245097116+58704) /500614~~512 


Solaris 的 REDO 块 较 小 ， 为 512 字 节 ; HP-UX 的 REDO 块 较 大 ， 为 1024 字 节 。 那 么 ， 当 有 1025 字 节 的 日 志 缓 存 需要 写 入 的 时 候 ，Solaris 下 需要 写 入 3 次 ，redo wastage 有 511 字 节 ; HP-UX 下 需要 写 2 


兴 


redo wastage 有 1023 字 节 ， 符 合 上 述 的 情况 。 相 比 之 下 ，Solaris 的 MO 交互 多 ， 且 后 台 进 程 之 间 的 message sent 多 ， 通 信 交 互 多 ， 导 致 性 能 慢 ， 似 乎 是 必然 的 。 


那 是 否 可 以 就 此 判定 Solaris 的 REDO 写 入 性 能 较 之 HP-UX 差 呢 ? 如 果 仅 依照 REDO 块 大 小 就 作出 判断 ， 显 然 是 非常 武断 的 。 


我 们 从 Oracle 数 据 库 层 | 


回 
对 


转 到 操作 系统 层面 再 来 考察 一 下 看 看 吧 。 对 于 以 上 测试 过 程 ， 在 操作 系统 上 跟踪 一 下 LGWR 进 程 的 操作 。 


HP-UX 平 台 下 使 用 tusc 跟 踪 工 具 ， 命 令 如 下 : 


Shell> tusc -Daef -o ora_hpux.1og -p 23257 


输出 的 日 志 如 下 : 

3305/9: 0.0077 pwrite(260, "01 "\0\0\003\080\0\0\0 g"http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.., 1048576, Ox06C 

3305/11: 0.8222 pwrite(260, "01 "\0\0\003\b80\0\0\0 g&"http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.., 104857 

3305/1: 0.8222 kaio(AIOWAIT, OxFFFFFFFF7FFFD600) =1 

3305/9: 0.8148 kaio(AIONOTIFY, 1) =0 

3305/11: 0.8318 kaio(AIONOTIFY, 1) =0 

3305/1: 0.8317 kaio(AIOWAIT, OxFFFFFFFF7FFFD600) =1 

3305/7: 1.6555 pwrite(260, "01 "\0\0\00312 b\0\0\0 g"http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.., 1048576, 0x062 

3305/7: 0.8181 kaio(AIONOTIFY, 1) =0 加 

3305/1: 0.8198 kaio(AIOWAIT, OxFFFFFFFF7FFFD600) =1 

3305/5: 2.4823 pwrite(260, "01 "\0\0\0031080\0\0\0 &g"http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.., 246784, 0x0621 

3305/11: lwp_ park (0x00000000, 0) (sleepinghttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/...) 

3305/9: 2.5005 pwrite(260, "01 "\0\0\0031A b\0\0\0 g"http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.., 423424, 0x0634 
wp_park (0x00000000, 0) (sleepinghttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/...) 


3305/7; 2 


Solaris 平 台 下 使 用 truss 跟 踪 工 具 ， 命 令 如 下 : 


Shell> truss -Daef -o ora_solaris.1og -p 24144 


输出 的 日 志 如 下 : 


12: 
12s 
123 
123 
12: 
23 
23 
12 


12s 


40:38 
bt 
40:38 
http: 
40:38 
http: 
40:38 
http: 
40:38 
http: 
40:38 
http: 
40:38 
http: 
40:38 
http 
40:38 
http 


10631] (0.000640) write (26218，"01B \O\0\006a9@ \0\0\02 80 bll4"http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Te 
//www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/OEBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teac 
10631] (0.071550) pw wait (Ox9fffffffffffcae0) http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/..http://www.hzc 
//www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/OEBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teac 
10631] (0.000023) lseek(26218, 447042560, SEEK SET) http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/..http://w 
//www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/OEBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teac 
10631] (0.007230) write (26218，"01B \O\0\006a9U \0\0\02 8010+ J "http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Te 
//wuw.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/..http://www.hzcourse.com/resource/readBook?path=/openresources/teac 
10631] (0.000019) lseek(26218, 448091136, SEEK SET) http: //www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/OEBPS/Text/. .http://« 
//waw.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teac 
10631] (0.000433) write(26218, "01B \0\0\006ady \0\0\02 80p ae8c"http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Te 
//wuw.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teac 
10631] (0.090776) pw wait (Ox9fffffffffffcae0) http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/. .http://www.hzc 
//wuw.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teac 
10631] (0.000023) lseek(26218, 448118784, SEEK SET) http: //www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/. .http://w 


://waw.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/..http://www.hzcourse.com/resource/readBook?path=/openresources/teac 


10631] (0.005320) write(26218, "01B \0\0\006agdp \0\0\02 8010fZ2a8"http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Te 


://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0OEBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teac 


统计 跟踪 输出 文件 ， 得 到 HP-UX 平 台 上 物理 写 入 的 次 数 为 539 次 ， 大 于 Oracle 上 看 到 的 285 次 ，Solaris 平 台 上 物理 写 入 次 数 为 408 次 ， 也 大 于 Oracle 上 看 到 的 306 次 ， 也 就 是 说 从 操作 系统 的 实际 写 入 行 
为 来 看 ，Solaris 反 而 是 有 优势 的 。 


REDO 块 的 大 小 只 代表 最 小 的 I/O 单 元 ， 不 能 简单 地 等 同 于 LGWR 进 程 写 入 性 能 差 ，LGWR 的 性 能 还 是 需要 结合 操作 系统 和 存储 层面 一 起 来 看 的 。 就 本 例 来 说 ，Solaris 平 台 的 写 入 比较 慢 ， 是 因为 存储 层 


的 性 能 


之 HP-UX 平 台 要 差 。 从 Oracle 10.2.0.4 版 本 开始 ， 如 果 LGWR 进 程 写 入 太 慢 ，Oracle 会 默认 写 警 告 信息 到 LGWR 进 程 的 跟踪 文件 。 


OT S022 15:35:53.997 
Warning: log write time 560ms, size 2984KB 
*** 2013-10-22 15:36:26.744 
Warning: log write time 3600ms, size 2938KB 
xy .20L3-10-22 15:36;35.855 
Warning: log write time 9100ms, size 8244KB 
S013-10-22 15:36:39.474 
Warning: log write time 36l0ms, size 2938KB 


对 于 一 套 并 发 写 操 作 比 较 多 ， 并 发 事务 比较 频繁 的 数据 库 ， 应 该 及 时 关注 LGWR 进 程 的 跟踪 文件 ， 尽 早 发 现 日 志 写 入 的 性 能 问题 。 如 果 出 现 问题 ， 可 以 考虑 从 LGWR 进 程 的 写 入 目标 ， 即 在 线 的 REDO 日 


志文 件 入 手 优化 ， 也 可 以 从 LGWR 进 程 本 身 入 手 优化 。 我 们 将 在 接 下 来 的 两 节 中 做 一 个 介绍 。 


5.2.2 DIOSAIO 


先 来 看 看 在 线 REDO 日 志文 件 的 存储 优化 吧 。 一 般 来 说 ， 我 们 会 将 在 线 REDO 日 志 分 为 多 个 分 组 (Group) 和 多 个 分 组 成 员 (Member) ， 并 且 将 不 同 的 分 组 成 员 存储 在 不 同 的 存储 卷 上 。 当 然 ， 这 种 做 
法 更 多 是 出 于 安全 的 考虑 。 那 么 ， 出 于 高 并 发 性 能 优化 上 的 考虑 ， 我 们 就 需要 在 存储 卷 上 做 文章 了 ， 这 要 结合 存储 和 操作 系统 两 个 层面 一 起 来 考虑 。 


存储 


当然 ， 也 可 以 选择 VO 能 力 更 强 的 存储 来 优化 REDO 的 写 入 性 能 ， 比 如 内 存 存 储 (Flash Cache) 和 分 层 存 储 。 我 们 将 会 在 本 书 第 二 部 分 中 展开 介绍 内 存 存储 对 提高 数据 库 并 发 容量 的 作用 。 


层面 的 优化 ， 是 不 是 立刻 会 联想 到 了 做 RAID 呢 ? 不 错 ，RAID 是 首先 要 保证 的 ， 想 必 不 会 有 谁 去 把 REDO 卷 放 在 RAID 5 的 存储 卷 上 吧 。 比 较 好 的 做 法 应 该 是 选择 RAID 0， 没 有 额外 的 写 和 校 验 ， 但 
是 往往 我 们 不 会 这 么 干 ， 在 数据 库 的 应 用 中 RAID 0 基本 上 都 被 RAID 1 + 0 或 RAID 0+ 1 所 取代 ， 为 了 保证 存储 的 安全 ， 宁 愿 辆 牲 掉 一 部 分 性 能 ， 我 们 说 这 样 的 策 牧 往往 都 是 值得 的 。 


操作 系统 层面 的 优化 ， 我 们 通常 会 从 以 下 三 项 中 选择 REDO 日 志文 件 的 存储 方式 : 
裸 设备 
-ASM 


ASM 方 式 是 一 个 不 错 的 选择 。 如 果 选 择 这 种 方式 ， 这 相当 于 将 这 部 分 的 优化 全 部 交 给 了 Oracle。 但 是 ， 在 非 RAC 的 应 用 中 ， 我 们 往往 更 倾向 于 选择 文件 系统 。 


操作 系统 为 了 提高 读 写 效 率 ， 会 为 文件 系统 开辟 一 块 区 域 用 于 读 写 数据 的 缓存 。 那 么 ， 用 创建 了 文件 系统 的 存储 卷 来 进行 在 线 REDO 日 志 的 存储 ，REDO 数 据 就 会 被 缓存 两 次 。 这 是 不 是 就 意味 着 需要 上 
裸 设备 来 存储 会 比较 好 呢 ? 裸 设备 虽然 没有 这 次 额外 的 缓存 ， 但 是 管理 成 本 相应 会 高 很 多 ， 因 此 是 不 推荐 的 。 就 好 像 在 ASM 出 现 之 前 ，RAC 都 是 架构 在 裸 设 备 上 的 ， 管 理 起 来 会 变 得 非常 麻烦 。 


就 文件 系统 来 说 ， 我 们 也 是 可 以 关闭 这 次 额外 缓存 的 ， 即 直接 Il/O (Direct MO) ， 简 称 DIO。 一 般 来 说 ， 对 于 写 操作 比较 密集 的 存储 卷 ， 我 们 可 以 实施 DIO。DIO 在 REDO 卷 的 应 用 中 ， 往 往 需 要 结合 
AlO 一 起 使 用 。 


AlO 是 异步 |/O (Asynchronous VO) 的 简称 ， 是 相对 于 同步 |/O (Synchronous MO) 来 说 的 。 在 同步 /O 模 式 下 ， 当 请 求 发 出 之 后 ， 应 用 程序 就 会 阻塞 ， 直 到 请 求 满足 为 止 ， 其 优点 在 于 应 用 程序 在 
桥 待 MO 请 求 完成 时 不 需要 使 用 CPU 资源 。 然 而 ， 对 于 一 些 并 发 要 求 比较 高 的 数据 库 应 用 系统 来 说 ， 我 们 更 看 重 的 是 较 高 的 响应 速度 ， 这 种 等 待 时 间 是 越 短 越 好 ， 此 时 就 需要 考虑 使 用 AIO 模 式 了 。 在 AIO 模 
式 下 ， 应 用 程序 发 出 MO 请 求 后 无 须 等 待 其 完成 ， 可 以 直接 处 理 其 他 事情 ，lMO 请 求 则 由 系统 进行 队列 管理 ， 一 旦 完成 ， 系 统 会 向 应 用 程序 发 出 通知 信号 。 


在 Oracle 数 据 库 的 应 用 中 ，AlIO 可 以 有 效 地 帮助 DBWn、LGWR 等 需要 频繁 快速 地 进行 MO 交互 的 进程 ， 其 MO 请 求 队列 化 管理 ， 充 分 利用 MO 带宽 ， 使 其 能 最 大 程度 提升 并 行 处 理 能 力 。 在 一 些 OLTP 应 
中 ，AIO 默 认 是 需要 打开 的 ， 如 果 写 并 发 压力 比较 大 ， 则 针对 REDO 存 储 卷 开启 DIO。 


那么 如 何 开启 AIO 和 DIO 呢 ? 
: 对 于 AIO 来 说 ， 首 先 需要 在 操作 系统 层面 进行 设置 ， 根 据 操作 系统 的 不 同 ， 其 设置 方法 也 是 不 一 样 的 ， 这 里 可 以 参考 操作 系统 的 操作 手册 (注意 不 是 每 一 种 操作 系统 都 能 支持 AIO 的 ) 。 


“ DIO 的 设置 依赖 于 文件 系统 类 型 ， 对 于 相同 操作 系统 上 的 不 同类 型 文件 系统 ， 其 设置 也 可 能 不 一 样 ， 具 体 方法 也 需要 参考 相关 操作 手册 。 一 般 来 说 ， 在 存储 卷 挂 载 到 操作 系统 的 时 候 ， 进 行 参数 设置 


就 可 以 实现 。 


进行 初始 化 参数 设置 : 修改 DISK_ASYNCH_10 参 数 为 TRUE 以 支持 AIO， 修 改 FILESYSTEMIO_OPTIONS 参 数 为 SETALL， 以 同时 支持 DIO 


当 操 作 系统 完成 AIO 和 DIO 设 置 后 ， 还 需要 在 Oracle 数 据 
和 AlO。 


其 
涪 
上 s 


FILESYSTEMIO_OPTIONS 参 数 说 明 : 
* NONE: 关闭 对 AIO 和 DIO 的 支持 (默认 值 ) ; 
“ ASYNCH: 支持 文件 系统 AIO; 
: DIRECTIO: 支持 文件 系统 DIO; 


“SETALL: 同时 支持 文件 系统 的 AIJO 和 DIO。 


5.2.3 ”进程 优先 级 


操作 系统 进程 的 优先 级 狐 似 和 并 发 处 理 优化 没有 什么 直接 的 关系 ,但 往往 它 在 哪里 ， 问 题 也 就 在 哪里 ， 解 决 了 它 ， 问 题 也 解决 了 。 这 里 再 来 介绍 一 个 高 并 发 处 理 相 对 集中 的 数据 库 案例 ， 也 可 以 说 和 前 
面 说 到 的 游标 争 用 是 同一 个 案例 。 


在 通过 上 述 分 散 游标 的 手段 一 定 程度 缓解 了 游标 争 用 的 问题 后 ，CPU 不 时 冲 高 的 现象 再 次 出 现 了 ， 现 象 如 下 : 


“ CPU 不 时 冲 高 ， 每 次 约 持续 时 间 有 几 分 钟 ; 
“ 伴随 着 cursor: bin S 的 等 待 事件 出 现 ; 
“ 单位 时 间 内 ， 导 致 游标 争 用 的 SQL 语句 执行 次 数 没有 明显 变化 ; 


: 出 现 连接 风暴 ， 单 位 时 间 内 的 logons cumulative 由 正常 的 300 多 舰 升 到 1100 多 。 


难道 是 之 前 的 优化 没有 起 作用 ? 不 是 的 ， 相 对 之 前 的 问题 ，CPU 冲 高 问题 的 严重 程度 明显 下 降 ， 出 现 频 度 也 明显 下 降 ， 那 问题 出 在 哪里 呢 ? 


此 时 ， 另 一 个 等 待 事件 的 出 现 吸引 了 大 家 的 眼球 ， 就 是 log file sync。 看 到 这 里 ， 第 一 反应 是 不 是 MO 性 能 变 差 ， 导 致 VO 等 待 和 会 话 阻塞 ， 进 而 造成 cursor: pin S 变 高 ，CPU 使 用 率 上 升 呢 ? 如 果 你 认 
为 我 们 要 简单 地 提高 LGWR 进 程 的 优先 级 ， 那 就 要 出 问题 了 。 


我 们 知道 在 log file sync 的 等 待 过 程 中 ， 最 消耗 时 间 的 部 分 应 用 是 log file parallel write， 如 果 是 REDO 卷 的 MO 性 能 出 现 问题 ， 必 然 会 反映 在 log file parallel write 等 待 事件 上 。 然 而 ， 如 表 5-9 所 示 ， 
在 本 例 中 : 


“ 问题 时 段 的 log file parallel write 相对 正常 时 段 没 有 太 大 区 别 ， 说 明 在 线 REDO 上 日 志 的 写 入 效率 没有 变 差 ，I/O 性 能 上 应 该 是 没有 问题 的 。 
“ 问题 时 段 的 log file sync 等 待 较 之 正常 时 段 却 有 了 明显 地 上 升 。 此 时 ， 由 于 问题 时 段 的 前 端 用 户 会 话 交互 行为 与 正常 时 段 没 有 太 大 的 变化 ， 那 问题 自然 就 出 在 了 LGWR 进 程 上 面 了 。 


“ log file sync 的 等 待 时 间 变 长 是 因为 CPU 的 紧张 ， 导致/O 〇 操作 完 之 后 ，LGWR 进 程 无 法 及 时 将 完成 的 消息 放 入 CPU 队 列 。 


表 5-9 LGWR 进 程 优先 级 之 log file sync 等 待 


问题 时 段 
log file parallel write 32 1 
二 log file sync 264 795 1 
正常 时 段 - - 


这 里 ， 我 们 要 先 引 进 一 个 操作 系统 对 进程 优先 级 差别 的 管理 方式 ， 如 果 操作 系统 的 进程 存在 优先 级 差别 ， 操 作 系 统 的 调度 会 将 CPU 占用 率 高 的 进程 降低 优先 级 。 


我 们 前 面 介绍 过 ， 会 话 在 申请 Latch 而 获取 不 到 时 ， 会 进入 SLEEP 状态 ， 并 释放 CPU ;而 申请 M utex 获 取 不 到 时 ， 并 不 会 真正 进入 SLEEP， 也 不 会 释放 CPU， 也 就 是 说 它 会 一 直 排 在 CPU 运行 队列 中 。 这 
样 ，Mutex 争 用 的 会 话 就 会 被 降低 CPU 优先 级 ， 而 其 他 进程 虽然 较 之 优先 级 高 了 ， 但 无 法 获得 相关 的 Mutex 资 源 ， 进 而 形成 了 一 种 “相互 等 待 ” 的 局 


对 


因此 ， 我 们 要 让 所 有 的 Oracle 进 程 处 于 同一 优先 级 ， 不 让 操作 系统 自动 降低 进程 的 优先 级 。 这 样 的 设置 在 一 些 高 并 发 的 数据 库 应 用 系统 中 ， 有 着 非常 积极 的 意义 。 


5.2.4 ”log file sync 分 析 


说 到 REDO 问 题 的 诊断 和 分 析 ， 似 乎 离 不 开 log file sync 等 待 事件 ， 而 说 到 log file sync 等 待 ， 不 同 的 人 也 许 又 有 着 不 同 的 见解 ， 而 且 听 上 去 都 不 无 道理 。 这 个 问题 也 一 度 成 为 DBA 面 试 时 面试 官 比较 喜 
好 的 问题 之 一 。 


对 于 log file sync 问 题 ， 我 也 有 着 自己 的 一 些 认识 和 观点 。 然 而 ， 当 看 到 Tanel Poder 对 该 问题 的 阐述 时 ， 我 觉得 更 为 专业 ， 更 为 深刻 。 这 里 引用 一 些 Tanel Poder 的 观点 ， 结 合 我 在 实际 应 用 中 的 案 
例 ， 为 大 家 展开 具体 分 析 。 


如 图 5-8 所 示 ， 依 照 时 间 轴 展开 LGWR 进 程 对 在 线 REDO 日 志 的 写 入 操作 : 


@ 用 户 提交 COMMIT 命 令 ; 


@ 前 台 触发 LGWR 进 程 ，LGWR 等 待 CPU 队列 ; 
@LGWR 提 交 IM/O 请 求 ， 进 入 SLEEP 状态 ; 
@I/O 过 程 ; 


@IO 完 成 ，LGWR 被 推 入 CPU 队列 ; 


@LGWR 在 CPU 上 运行 ， 返 回信 息 给 前 台 ; 


@COMMIT 命 令 完成 ， 前 台 获得 返回 信息 ， 进 入 CPU 队列 。 


时 间 轴 


log file parallel write 
log file Sync 


| | 前 台阶 段 | | LGWR 阶 段 [| | vo 阶段 


图 5-8 ”log file sync 分 析 图 
再 来 看 一 下 等 待 事件 : 


:一旦 LGWR 进 程 被 触发 ，log file sync 等 待 就 开始 了 ， 直 到 LGNWR 返 回 完成 信息 给 前 台 ， 等 待 方 告 结束 。 


“ 而 log file parallel wtite 的 等 待 是 被 包含 在 log file sync 等 待 时 间 区 间 内 的 ， 该 事件 的 等 待 与 1/O 〇 行为 直接 相关 ， 若 I/O 〇 请 求 提交 ， 则 等 待 开始 ,，I/ 〇 完成 信息 提交 给 LGWR 后 等 待 结 


可 以 看 到 ， 整 个 过 程 跨越 前 台 、LGWR、1/O 三 个 阶段 。 在 通常 情况 下 ，I/O 阶 段 是 耗 时 最 高 的 ， 集 中 表现 在 |/O 写 入 行为 的 过 程 (步骤 @) 。 但 这 反映 的 只 是 一 个 通常 情况 ， 比 如 上 述 的 一 个 案例 ，log 
file parallel write 等 待 并 没有 明显 升 高 ， 但 log file sync 等 待 却 明 显 升 高 ， 从 时 间 轴 上 看 ， 整 个 过 程 被 卡 在 步骤 @ 和 步骤 @ 之 间 ，LGWR 进 程 在 等 待 进 入 CPU 队 列 。 


从 以 上 观点 不 难得 知 ， 三 个 阶段 的 阻塞 都 可 能 导致 高 log file sync 的 等 待 。 大 致 可 以 包括 : 
: 事务 (commit 或 rollback) 等 待 太 久 : 
“用户 commit/rollback 操 作 过 于 频繁 与 密集 ; 
“ 递归 事务 提交 ， 数 据 字 典 递归 DML 操作; 
“ 内 部 回 滚 、ASSM 空 间 的 分 配 、 事 务 中 断 、 中 断 会 话 等 。 
: CPU 资源 争 用 : 
“ 其 他 原因 导致 的 CPU 资源 争 用 ， 累 及 LGWR 进 程 无 法 进入 CPU 运行 队列 。 
. REDO 存 储 卷 I/O 能 力 缓慢 : 
“I/O 〇 能 力 缓慢 无 疑 是 最 致命 的 ， 因 为 实际 I/O 〇 行为 往往 是 最 耗 时 的 。 


“ 过 大 的 日 志 缓 存 : 


过 大 的 日 志 缓存 有 可 能 导致 LGCWR 进 程 的 “懒惰 ”， 使 得 LGWR 的 触发 频率 变 低 ， 日 志 缓存 的 内 容 不 能 及 时 写 到 REDO 日 志文 件 。 而 一 旦 触发 写 入 操作 ，JMO 压 力 变 大 ， 争 用 发 生 的 几率 也 变 大 。 


现在 再 来 思考 如 何 解决 log file sync 问 题 ， 是 不 是 有 一 种 雁 然 开朗 的 感觉 呢 ? 当然 ， 也 还 是 需要 先 明 确 问题 的 具体 起 因 


“ 避免 频繁 密集 的 事务 提交 和 回 退 ， 尽 可 能 采用 批量 提交 作为 替代 ; 


“ 采用 I/O 〇 能 力 更 强 的 存储 设备 对 在 线 REDO 日 志文 件 进行 存储 ， 如 内 存 存 储 、 


. 在 REDO 卷 上 开启 AIO 和 DIO; 


“ 设置 合理 大 小 的 日 志 缓 存 ; 


: 关注 CPU 争 用 ， 防 止 LGWR 进 程 被 累及 。 


5.3 ”本 章 小 结 


纵 观 本 章 ， 都 是 在 结合 一 些 实际 高 并 发 解决 案例 给 大 家 
知 到 问题 的 根源 ， 对 高 并 发 问题 金 底 抽 薪 。 下 一 


分 层 存 储 ; 


纵 者 ， 合 众 弱 以 攻 一 强 也 ; 横 者 ， 事 一 强 以 攻 众 弱 也 。 


第 6 章 TimesTen 内 人 存 数据 库 


本 章 要 点 : 


' TimesTen 概 述 ， 介 绍 TimesTen 内 存 数据 库 的 前 世 今 生 。 


“ 开始 使 用 


， 介 绍 TimesTen 数 据 库 的 安装 配置 技巧 。 


“ 缓存 集合 管理 ， 介 绍 TimesTen 作 为 Oracle 缓 存 数 据 库 的 应 用 。 


“ 高 可 用 复制 架构 ， 介 绍 如 何 使 用 复 
“ 高 可 用 网 格 架构 ， 
“ 分 库 分 表 ， 介 绍 如 何 使 用 TimesTen 搭 建 分 布 式 数 
:TimesTen 设 计 与 管理 ， 介 绍 表 和 索引 设计 ， 统 计 


:TimesTen 性 能 监控 ， 介 绍 TimesTen， 


功能 实现 数 
介绍 如 何 使 用 网 格 功能 实现 数 


据 库 应 用 。 


使 用 的 典型 监控 方法 。 


:TimesTen 备 份 与 恢复 ， 介 绍 TimesTen 的 备份 恢复 及 数据 迁移 。 


' TimesTen 高 并 发 场景 ， 
纵 者 ， 合 众 弱 以 攻 一 强 也 ; 横 者 ， 事 一 强 以 攻 众 弱 也 。 合 纵 的 策略 ， 就 是 联合 众多 弱 国 
战国 
导向 ， 善 谋 善 断 ， 术 无 定 术 ， 法 无 常 法 ， 其 大 道 就 是 实 


纵横 之 术 之 所 以 被 称 为 纵横 之 术 ， 而 非 纵 术 或 是 横 术 ， 是 
其 他 数据 库 各 有 各 的 优势 ， 如 果 一 味 只 


介绍 TimesTen 的 并 发 场景 选择 和 评估 。 


第 二 部 分 


据 库 容 灾 扩 展 等 架构 设计 。 


据 库 的 负载 均衡 与 高 可 用 。 


信息 、 执 行 计划 在 TimesTen 中 的 应 用 。 


来 攻打 一 个 强国 


展开 介绍 的 。 在 这 里 ， 我 们 不 可 能 覆盖 到 所 有 的 具体 问题 ， 只 希望 能 够 通过 一 种 方法 的 分 享 ， 使 读者 能 对 高 并 发 问题 有 更 好 的 把 握 ， 更 清晰 地 探 
我 们 将 进入 第 二 部 分 纵横 篇 ， 深 入 介绍 TimesTen 内 存 数据 库 。 


纵横 篇 


一 一 韩非子 ，《 韩 非 子 》 


; 连 横 的 策略 ， 则 是 侍奉 一 个 强国 来 攻打 各 个 弱 国 。 


Z 


时 期 ， 苏 秦 和 张仪 凭借 卓越 的 纵横 之 术 ，“ 翻 手 为 云 ， 履 手 为 雨 ” ， 操 纵 着 战国 斗争 的 局 势 ， 
、 效 果 好 ， 不 拘泥 于 形式 。 


为 其 


导 思 想 还 是 明确 的 目标 导向 ， 只 要 能 达成 目标 ， 是 纵 是 横 并 不 重 


数据 库 森 林 体系 ， 施 以 纵横 之 术 。 


经 过 第 一 部 分 的 内 政 篇 介绍 ， 相 信 读 者 对 核心 的 Oracle 数 据 库 已 经 可 以 做 到 游 思 有 余 了 ， 在 接 下 来 的 第 二 部 分 中 我 们 将 展开 介绍 周边 的 辅 
辅助 的 数据 库 往往 成 了 决定 成 败 的 关键 所 在 ， 比 如 本 章 将 要 展开 介绍 的 TimesTen 内 存 数据 库 。 


6.1 


TimesTen 概 述 


横 术 ， 而 排斥 其 他 数据 库 ， 那 应 


并 最 终 缔造 出 神州 大 一 统 的 辉煌 帝国 。 纵 横 之 术 也 被 认为 最 务实 之 术 ， 一 切 以 实际 出 发 ， 明 确 的 目标 


就 好 。 在 现今 的 数据 库 技术 领域 里 ，Oracle 还 是 一 方 强 者 ， 


， 适 


将 被 完全 颠覆 。 比 较 好 的 做 法 在 第 1 章 中 已 经 介绍 过 了 : 实现 


也 将 会 受到 诸多 制约 ， 如 果 一 味 只 


纵 术 ， 言 必 称 去 IOE， 那 么 应 


说 到 内 存 数据 库 ， 你 是 否 还 有 些 陌生 呢 ? 相信 在 这 个 内 存 为 王 的 云 计 算 和 大 数据 的 时 代 ， 内 存 数 


及 MySQL 的 内 存 存储 引擎 ， 等 等 ， 这 些 原 本 陌生 或 者 刚 出 道 不 久 的 内 存 数据 库 技 术 ， 像 是 雨后春笋 一 样 ， 接 二 连 三 地 冒 出 来 了 ， 


数 据 库 应 用 。 虽 说 是 辅助 的 数据 库 ， 但 在 很 多 情况 下 ， 这 些 


居 库 已 经 被 很 多 人 所 熟知 了 。Oracle TimesTen、Redis、SAP HANA、Oracle In-Memory Option 以 
不 暇 接 之 余 ， 另 一 个 问题 就 出 现 了 : 如 何 选 择 和 应 用 ? 


核心 的 数据 库 森 林 体系 中 ，TimesTen 内 存 数据 库 将 会 帮助 我 们 达成 这 个 目标 。 


Gl,l 


TimesTen 历 史 与 定位 


前 面 我 们 已 经 说 过 ， 一 项 技术 或 产品 的 选择 ， 都 是 由 需求 所 驱动 的 ， 没 有 万 能 的 技术 ， 只 有 万 变 的 需求 。 本 书 的 主旨 就 是 通过 一 些 手段 来 解决 高 并 发 的 问题 ， 那 么 基于 这 个 目的 ， 在 以 Oracle 数 据 库 为 


罗马 不 是 一 天 建成 的 ，TimesTen 内 存 数 据 库 虽 然 比 不 上 Oracle 数 据 库 那样 历史 悠久， 但 也 是 经 年 地 沉淀 和 积累 造就 的 。 


先 来 看 一 下 TimesTen 发 展 历史 的 几 个 重大 事件 吧 : 


“ 1992 年 ，TimesTen 在 HP 美国 总 部 第 一 个 内 存 数 据 库 的 实验 室 诞生 ， 主 要 研究 内 存 数据 库 技术 在 电信 网 络 中 的 应 用 ; 
:1996 年 ，TimesTen 从 HP 实验 室 分 离 出 来 ， 成 立 了 一 家 独立 的 内 存 数 据 库 公 司 ; 

1998 年 ， 发 布 了 第 一 个 内 存 数据 库 的 商用 版 本 ; 

: 1999 年 ，Timesten 在 伦敦 开业 ; 

“ 2005 年 ，Oracle 收 购 了 Timesten， 并 推出 主要 的 商用 版 本 (TimesTen 6.0) ， 拥 有 超过 1500 家 企业 级 的 用 户 ; 


" 2007 年 ，Timesten 新 版 本 7.0 正 式 推出 。 


纵 观 TimesTen 的 发 展 历史 ， 其 中 最 关键 的 一 个 事件 应 该 是 2005 年 被 Oracle 公 司 收购 。Oracle 在 收购 TimesTen 内 存 数 据 库 之 后 ， 开 始 了 对 该 产品 的 功能 整合 。 经 过 几 个 版 本 的 改进 后 ， 基 本 上 实现 了 
TimesTen 与 Oracle 数 据 库 的 完美 对 接 。 目 前 来 看 ，TimesTen 内 存 数据 库 可 以 独立 成 库 ， 也 可 以 作为 Oracle 数 据 库 的 一 个 前 置 缓存 数据 库 ， 就 像 Oracle 伸 出 去 的 一 只 手 ， 专 门 用 作 内 存 的 计算 和 处 理 。 


当然 ， 现 在 市 面 上 也 不 乏 其 他 优秀 的 内 存 数据 库 产 品 ， 功 能 上 也 各 有 优势 ， 但 要 说 到 与 Oracle 数 据 库 的 兼容 性 ，TimesTen 将 是 首屈一指 的 ， 甚 至 你 可 以 将 其 作为 Oracle 数 据 库 的 一 个 组 件 来 进行 规划 和 
使 用 。 


再 从 技术 层面 上 来 考察 一 下 TimesTen 内 存 数据 库 吧 。 图 6-1 标 记 了 TimesTen 在 技术 发 展 上 的 重大 记事 。 自 从 2005 年 被 Oracle 收 购 之 后 ，TimesTen 内 存 数据 库 在 功能 上 也 吸收 了 很 多 Oracle 数 据 库 的 成 
熟 特 性 ， 进 一 步 黄 定 了 其 在 内 存 数 据 库 领域 的 核心 地 位 。 


2005 
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图 6-1 TimesTen 的 历史 


如 果 说 核心 数据 库 用 的 不 是 Oracle 数 据 库 ，TimesTen 是 否 可 以 使 用 呢 ? 回答 是 肯定 的 ， 因 为 TimesTen 也 可 以 独立 成 库 ， 与 同类 产品 相 比 ， 也 是 相当 有 竞争 力 的 。 本 书 就 不 做 过 多 的 商业 推广 了 。 
6.1.2 TimesTen 应 用 场景 


在 谈论 TimesTen 内 存 数 据 库 应 用 场景 之 前 ， 我 们 先 来 介绍 一 下 什么 是 内 存 数据 库 ， 以 及 其 工作 原理 吧 。 内 存 数据 库 ， 顾 名 思 义 就 是 将 数据 存放 在 内 存 中 ， 并 通过 内 存 操作 直接 完成 数据 库 相关 操作 。 与 
磁盘 相 比 ， 数 据 在 内 存 中 的 读 写 速度 要 高 出 几 个 数量 级 ， 能 够 极 大 地 提高 应 用 程序 的 性 能 。 同 时 ， 内 存 数据 库 抛弃 了 磁盘 数据 管理 的 传统 方式 ， 基 于 全 部 数据 都 在 内 存 中 ， 重 新 设计 了 体系 结构 ， 并 且 在 数 
据 缓存 、 快 速算 法 、 并 行 操作 方面 也 进行 了 相应 的 改进 ， 所 以 数据 处 理 速 度 比 传统 数据 库 的 数据 处 理 速 度 要 快 很 多 ， 一 般 都 在 10 倍 以 上 ，TimesTen 也 由 此 而 得 名 。 内 存 数据 库 从 某 种 角度 上 来 看 ， 也 是 一 种 
缓存 机 制 ， 是 磁盘 数据 库 的 前 端 缓存 ， 通 过 物理 内 存 中 的 数据 存储 区 的 直接 操作 ， 减 少 了 到 磁盘 间 的 MO 交互 。 


说 到 应 用 场景 ，TimesTen 内 存 数据 库 也 不 是 万 能 的 ， 不 是 什么 场景 都 适合 使 用 TimesTen 的 。 在 实际 工作 中 ， 我 不 只 一 次 地 被 问 及 : “如 果 使 用 TimesTen， 我 们 的 应 用 程序 是 不 是 就 能 提升 性 能 


呢 ? ”我 只 能 说 : “TimesTen 也 是 有 作用 域 的 ， 不 是 什么 场景 都 适合 。 判 断 是 否 适合 ， 我 们 需要 做 一 次 完整 的 应 用 POC 测 试 才能 判定 。” 与 使 用 其 他 工具 是 一 样 的 ， 要 使 用 TimesTen 内 存 数据 库 ， 需 要 先 


1.TimesTen 特 点 


加 6-2 对 比 了 Oracle 数 据 库 与 TimesTen 内 存 数据 库 在 应 用 程序 SQL 语句 从 执行 到 返回 的 过 程 ， 可 以 看 到 TimesTen 内 存 数据 库 具 有 以 下 优势 ; 


:完全 内 存 存储 和 内 存 读 写 ， 没 有 缓冲 缓存 管理 开销 ; 


“ 更 短 的 SQL 路 径 导 致 更 快 的 性 能 ， 更 少 的 CPU 指令 导致 更 少 的 CPU 开销 。 


确定 磁盘 地 址 和 预期 数据 
确定 内 存 地 址 和 预期 数据 


， 为 存 映 息 
应 用 SQL 查询 & 执 行 


内 存 寻 址 


内 存 数据 库 


返回 应 用 


口上 口 口 口 


从 磁盘 整合 数据 到 内 存 
通过 哈 希 线形 查询 确定 数据 指针 


Oracle 数 据 库 


从 以 上 对 比 中 ， 我 们 可 以 归 总 一 个 结论 : TimesTen 的 数据 读 写 速度 快 ， 事 务 并 发 处 理 能 力 强 。 但 是 也 需要 关注 到 TimesTen 的 一 些 限制 。TimesTen 在 进行 架构 设计 的 时 候 ， 有 以 下 几 个 关注 点 : 


“ 拒绝 热点 争 用 ， 高 并 发 的 热点 争 用 更 易 产 生 CPU 问 题 ; 


“ 高效 [/O 要 求 ，TimesTen 的 数据 文件 和 日 志文 件 均 存 储 在 磁盘 上 ， 与 内 存 保持 同步 ， 如 果 磁 瘟 LI/O 不 佳 会 成 为 性 能 短 板 ; 


匡 


库容 量 不 宜 过 大 ， 会 导致 恢复 成 本 高 
“ 字段 不 宜 过 长 ， 内 存 存 储 比 磁盘 存储 更 消耗 容量 。 


换 而 言 之 ,我 们 在 享受 TimesTen 内 存 数据 库 带 来 的 高 性 能 和 高 并 发 优势 的 同时 ， 需 要 注意 由 此 而 可 能 出 现 的 问题 点 。TimesTen 的 高 速 也 是 需要 有 代价 的 ， 是 需要 建立 在 优秀 架构 设计 的 基础 上 。 与 
Oracle 厚 重 的 基础 架构 相 比 ，TimesTen 显 得 有 些 “ 单 薄 ” ， 更 像 是 一 个 敏捷 数据 库 ， 在 使 用 过 程 中 ， 我 们 应 该 尽 可 能 地 遵守 “ 快 进 快 出 ”的 原则 ， 一 些 比较 厚重 的 应 用 并 不 适合 使 用 TimesTen 数 据 库 。 


2. 适 用 场景 和 注意 事项 


归 总 一 下 ， 有 哪些 场景 适合 使 用 TimesTen 吧 : 


“ 业务 逻辑 简单 、 快 速 响应 的 OLTP 应 用 ， 比 如 互联 网 秒杀 活动 、 网 上 拍卖 、 电 子 计 费 等 ; 
:Oracle 数据 库 并 发 争 用 压力 过 大 的 应 用 ， 可 以 分 离 到 TimesTen 上 ， 通 过 分 库 分 表 实现 快速 响应 ; 


' 对 于 一 些 数据 量 较 大 、 业 务 逻 辑 复杂 、 数 据 耦 合 性 非常 强 的 应 用 ， 如 MIS、OLAP， 将 不 是 TimesTen 所 擅长 处 理 的 。 


TimesTen 内 存 数据 库 的 最 大 优势 是 解决 高 并 发 争 用 压力 ， 同 时 在 响应 时 间 上 作出 优化 ， 不 是 从 分 钟 级 到 秒 级 的 优化 ， 而 是 从 秒 级 到 毫秒 级 的 优化 ， 这 才 是 其 最 擅长 的 。 在 使 用 设计 上 需要 注意 以 下 方 
面 : 


“ 表 、 索 引 结构 设计 简单 ， 字 段 长 度 较 短 ， 且 尽 可 能 只 使 用 常用 字段 类 型 ; 
“ 函数 、 存 储 过 程 、 序 列 等 数据 库 对 象 尽量 不 使 用 ; 
“SQL 语句 简单 (不 含 复杂 的 表 关联 和 子 查 询 等 ) ， 单 条 语句 响应 时 间 尽 量 能 控制 在 毫秒 级 ; 


“ 如 果 作 为 Oracle 的 前 置 缓存 ， 数 据 刷新 频率 不 宜 过 高 。 


6.1.3 TimesTen 技 术 架 构 


接 下 来 ， 我 们 就 从 应 用 形式 、 内 部 架构 、 连 接 方式 、 高 可 用 形式 四 个 方面 来 进行 一 个 TimesTen 技 术 架 构 的 概述 。 


1. 应 用 形式 


前 面 


' TimesTen 内 存 数据 库 (TimesTen In-Memory Database) : 


用 程序 层 


说 到 ，TimesTen 可 以 单独 使 用 ， 也 可 以 作为 Oracle 的 缓存 来 使 用 ， 这 里 我 们 就 先 来 介绍 一 下 TimesTen 内 存 数 据 库 的 使 有 


形式 ， 


具体 如 下 : 


中 ， 利 用 标准 的 SQL 接口 对 完全 位 于 物理 内 存 中 的 数据 存储 进行 操作 。 


它 是 一 个 针对 内 存 进 行 了 优化 的 关系 数据 库 ， 它 为 应 用 程序 提供 了 即时 响应 性 和 非常 高 的 吞吐 量 。TimesTen 作 为 缓存 或 议 入 式 数据 库 部 署 在 应 


"Oracle 数据 库 缓 存 (Oracle In-Memory Database Cache) : 它 是 一 个 数据 库 选 件 ， 它 与 Oracle 数 据 库 配合 使 用 ， 作 为 Oracle 数 据 库 的 一 个 高 速 缓存 ， 为 前 端 应 用 提供 了 实时 、 可 更 新 的 缓存 。 它 将 来 自 数据 


库 的 、 对 


性 能 极其 关键 的 一 系列 表 缓存 到 应 用 程序 层 ， 从 而 缩短 应 用 程序 事务 响应 时 间 。 


2. 内 部 架构 


知 其 


若 要 


然 需 知 其 所 以 然 ，TimesTen 的 高 并 发 处 理 优势 源 自 何 处 呢 ? 我 们 需要 来 深入 研究 一 下 它 的 技术 架构 。 


求 快速 的 响应 ， 就 需要 简单 高 效 的 架构 来 作为 保障 ， 如 图 6-3 所 示 ， 和 Oracle 数 据 库 一 样 ，TimesTen 的 架构 中 也 可 以 分 为 三 个 部 分 : 


存 结构 : 负责 与 前 端 应 用 的 数据 交互 和 直接 的 数据 库 操作 


台 进程 : 负责 应 用 、 内 存 结构 、 文 件 结构 之 间 的 交互 ， 作 用 就 像 通讯 员 一 样 ; 


“ 文件 结构 : 与 内 存 的 交互 ， 存 储 数据 库 到 磁盘 ， 并 记录 相关 上 日志。 需要 注意 的 是 ， 和 Otacle 不 同 ， 文 件 和 内 存 的 交互 是 在 后 台 异 步 完成 的 ， 不 会 直接 影响 到 应 用 与 内 存 交 互 的 性 能 。 


后 台 进 各 


(1) 


先 来 


内 存 结 构 


引擎 (ODBC/JDBC 驱 动 器 ) 


Sub 
Daemon 


sys.odbc.ini 


配置 文件 


ttmesg.log 检查 点 文件 


徊 告 日 志文 件 


文件 结构 


6-3 TimesTen 技 术 架 构 


内 存 结构 


看 一 下 内 存 结构 吧 。 在 内 存 结构 中 ， 包 含 如 下 三 个 主体 结构 。 


“ Data Store: 保存 所 有 数据 库 数 据 的 区 域 ， 我 们 将 其 视 为 一 个 独立 的 数据 库 ， 可 以 对 应 Oracle 的 数据 文件 和 高 速 缓存 的 合集 ， 只 不 过 存储 位 置 完全 在 内 存 区 域 ; 


“ 笠 


志 缓存 : 用 于 暂时 存储 记录 Data Store 变 更 的 日 志 ， 可 以 对 应 到 Oracle 的 SGA 共 享 内 存 区 域 的 日 志 缓存 (Log Buffer) ; 


“ 临时 数据 区 域 : 临时 存储 执行 计划 等 数据 的 共享 区 域 ， 供 排序 等 操作 临时 使 用 。 相 比 Oracle，TimesTen 在 此 处 作出 了 结构 上 的 简化 ， 可 以 视 为 Oracle 的 多 个 内 存 区 域 的 合集 。 也 正 因为 这 样 的 简 
化 ，TimesTen 在 使 用 上 就 必须 保证 简单 化 ， 否 则 争 用 热点 出 现 ， 其 性 能 甚至 可 能 不 如 Oracle 数 据 库 。 


在 


局 


(2) 


后 台 


用 程序 和 主体 内 存 结构 之 间 ， 还 架设 了 一 层 TimesTen 的 引擎 ， 其 需要 在 配置 文件 中 进行 具体 的 指定 ， 功 能 为 执行 SQL 语句 并 返回 
后 台 进 程 
进程 可 以 分 为 常 驻 进程 和 可 选 进程 两 种 ， 常 驻 进程 是 TimesTen 数 据 库 所 必需 的 ， 包 括 : 


执行 结果 。 


' 主 进程 (Daemon) : 负责 监听 功能 (Listener) ， 读 取 配 置 文件 信息 ， 以 及 分 配 和 监视 子 进 程 。 


“ 子 进程 (Sub Daemon) : 负责 加 载 和 趣 载 Data Store， 将 日 志 缓 存 写 入 日 志文 件 ， 监 视 和 解除 死 锁 及 执行 检查 点 。 


如 果 需 要 实现 TimesTen 数 据 库 与 Oracle 数 据 库 交互 的 高 可 用 架构 ， 可 选 进程 也 是 不 可 少 的 。 可 选 进程 主要 包括 以 下 几 个 


“ 复制 代理 (Replication Agent) : 用 以 实施 TimesTen 主 备 数 据 库 直接 的 复制 工作 ， 以 及 AWT 缓 存 集合 的 数据 刷新， 以 保证 数据 库 高 可 用 ， 有 些 类 似 于 Oracle 的 Data Guard， 但 是 相对 来 说 ， 结 构 较 为 简 
单 。 

“ 缓存 代理 〈(Cache Agent) : 实施 缓存 连接 ， 开 启 缓存 代理 后 ， 可 以 在 TimesTen 和 Oracle 之 间 开 启 心 跳 连 接 ， 并 且 数 据 定 时 刷新 ， 使 得 TimesTen 成 为 Oracle 的 前 置 缓存 数据 库 。 

“Server 进 程 : 当 TimesTen 采 用 C/S 连 接 模式 时 ， 响 应 客户 端 连接 的 服务 器 进程 。 

.Process 进 程 : 当 TimesTen 采 用 Direct 连 接 模式 时 ， 响 应 连接 请 求 的 进程 。 

(3) 文件 结构 


最 后 来 看 一 下 TimesTen 数 据 库 的 文件 结构 ， 是 否 可 以 看 到 一 些 Oracle 的 影子 呢 ? 麻雀 虽 小 ， 五 脏 俱全 ，TimesTen 的 文件 结构 包括 以 下 文件 。 


“ 配置 文件 : 
“sys.odbc.ini 文 件 : 记录 TimesTen 服 务 器 端的 配置 信息 ， 包 括 : 服务 器 端 基本 配置 和 各 个 Data Store 的 初始 化 参数 ; 
“sys.ttconnect.ini 文 件 : 记录 客户 端 连接 的 配置 信息 ， 如 果 需 要 使 用 C/S 连 接 模式 ， 就 需要 配置 该 文件 ; 
“ ttendaemon.options: 记录 TimesTen 主 进程 所 需要 的 配置 信息 ， 包 括 后 台 日 志 目 录 、 日 志 大 小 、C/S 连 接 端 口号 、TNS_ADMIN 目 录 等 。 
“ 警告 日 志文 件 : ttmesglog 记 录 的 是 TimesTen 运 行情 况 的 日 志 ， 有 些 类 似 于 Oracle 的 alert.log 文 件 ; 
“tterrors.log 则 记录 的 是 报错 信息 ， 有 些 类 似 于 Oracle 的 系统 进程 跟踪 文件 ; 
“ instance_info 用 来 记录 该 主机 上 安装 过 的 TimesTen 软 件 信 息 ， 包 括 版 本 、 软 件 目录 、 主 进程 端口 号 等 。 


“在线 日 志文 件 : 


的 机 制 ， 日 志 的 数量 会 一 直 


可 以 视 为 Oracle 的 在 线 重 做 日 志文 件 和 归档 重 做 日 志文 件 的 合集 ， 在 TimesTen 中 是 没有 两 者 概念 之 分 的 ， 都 称 为 在 线 日 志文 件 。 与 Oracle 不 一 样 的 是 ， 其 没有 循环 重复 使 有 
增加 ， 需 要 定期 清理 ， 当 满足 如 下 条 件 时 ， 会 自动 清理 过 期 日 志文 件 : 


“ 关联 事务 已 经 全 部 提交 完成 的 ; 
“ 检查 点 文件 不 再 需要 的 日 志文 件 ; 
“ 复制 代理 不 再 需要 的 日 志文 件 ; 
Oracle 缓存 连接 的 缓存 代理 不 再 需要 的 日 志文 件 ; 
“ 如 果 数 据 库 进行 过 备份 ， 则 同时 备份 集中 已 经 包含 的 日 志文 件 。 
' 预 留 日 志文 件 : 也 可 以 称 为 恢复 日 志文 件 ， 是 在 TimesTen 宕 机 时 恢复 使 用 ， 如 磁盘 空间 满 了 ，TimesTen 会 使 用 该 预 留 的 日 志文 件 记 录 日 志 ， 保 证 不 丢 数 据 ( 每 个 Data Store 只 能 配置 3 个 预 留 日 志文 
件 ) 。 


“ 检查 点 文件 : 这 类 文件 也 是 TimesTen 比 较 特别 之 处 ， 我 们 可 以 视 其 为 数据 文件 ， 主 要 用 来 记录 和 同步 Data Store 的 内 存 数 据 ， 是 内 存在 磁 瘟 上 的 一 个 镜像 。 当 TimesTen 重 启 或 恢复 的 时 候 ， 子 进程 会 将 
检查 点 文件 的 数据 重新 加 载 到 Data Store 内 存 区 域 。 


每 个 TimesTen 实 例 有 两 个 检查 点 文件 ， 在 做 检查 点 操作 的 时 候 会 交 蔡 写 入 这 两 个 文件 ， 两 个 检查 点 文件 之 间 存 在 一 定 的 时 间 间 隔 。 在 TimesTen 数 据 库 中 ， 有 三 种 类 型 的 检查 点 : 


“ 阻塞 (Blocking) 检查 点 ， 做 该 检查 点 操作 时 会 加 上 数据 库 级 别 的 锁 ， 它 是 一 个 完全 检查 点 ， 必 须 保证 事务 的 一 致 性 ; 
“ 非 阻塞 (Fuzzy) 检查 点 ， 做 检查 点 时 不 会 加 数据 库 级 别 的 锁 ， 不 影响 应 用 使 用 ， 通 常数 据 库 工作 时 周期 性 进行 的 就 是 该 类 检查 点 ， 它 是 一 个 不 完全 检查 点 ， 不 必 保 证 事务 的 一 致 性 ; 


“ 静态 (Static) 检查 点 ，TimesTen 实 例 在 创建 和 和 印 载 的 时 候 会 做 这 种 类 型 的 检查 点 ， 此 时 不 论 是 否 存 在 脏 数 据 块 ， 都 会 全 库 写 一 遍 数 据 文件 。 


需要 注意 的 是 ，TimesTen 与 Oracle 不 一 样 ， 没 有 那么 复杂 的 后 台 进程 配置 和 触发 关系 ， 内 存 与 检查 点 文件 的 记录 和 同步 都 是 通过 子 进程 来 完成 的 。 


为 什么 TimesTen 需 要 配置 两 个 检查 点 文件 呢 ? 主要 还 是 为 了 保证 数据 元 余 和 快速 恢复 ， 当 一 个 检查 点 失败 ， 数 据 库 死机 了 ， 也 可 以 通过 男 一 个 检查 点 文件 快速 进行 日 志 恢 复 。 然 而 ， 因 为 有 两 个 检查 
点 ,使 得 TimesTen 内 存 与 文件 系统 的 |/O 交 互 压力 也 相应 增 大 了 ， 内 存 数 据 库 对 前 端 应 用 是 没有 I/O 的 ， 但 后 台 交 互 的 |/O 问 题 是 不 能 小 视 的 。 


3. 连 接 方式 


当 应 用 端 向 TimesTen 数 据 库 发 起 连接 的 时 候 ， 主 要 可 以 有 两 种 连接 的 模式 : 


(1) 直接 (Direct) 连接 模式 


Oracle 推 荐 的 连接 方式 ， 具 有 最 佳 的 性 能 ，TimesTen 数 据 库 与 中 间 件 部 署 在 同一 台 主机 上 ， 同 处 于 中 间 件 层 ， 应 用 程序 通过 ODBC/JDBC 直 接 对 数据 库 进 行 访问 ， 与 传统 的 C/S 模 式 相 比 ， 减 少 了 
TCP/IP、IPC 方 面 的 开销 。 


然而 ，TimesTen 和 中 间 件 部 署 在 同一 台 主 机 上 ， 一 定 程度 上 增加 了 运 维 的 风险 。 


(2) 客户 端 /服务 器 (C/S) 连接 模式 


传统 的 连接 方式 ， 性 能 比 直接 驱动 器 连接 差 ，TimesTen 数 据 库 与 中 间 件 处 于 不 同 的 主机 上 ， 客 户 端 与 服务 器 一 般 以 TCP/IP 方 式 连接 ， 存 在 网 络 开销 。 


从 性 能 上 来 看 ， 直 接连 接 的 模式 是 有 优势 的 ， 但 也 不 是 说 应 用 程序 就 一 定 要 选择 该 连接 模式 ， 还 是 需要 考虑 在 运 维 方面 是 否 能 够 接受 因此 而 带 来 的 风险 。 另 一 角度 来 看 ，TimesTen 通 常 是 作为 数据 库 来 
进行 运 维 的 ， 被 定义 在 数据 库 层 ， 而 直接 连接 的 模式 要 求 将 其 置 于 中 间 件 层 进行 部 署 与 运 维 ， 需 要 考虑 在 跨 部 门 合作 上 的 风险 是 否 可 以 接受 。 


4. 高 可 


用 形式 


我 们 说 过 TimesTen 可 以 通过 复制 代理 的 方式 实现 类 似 于 Oracle 数 据 库 Data Guard 的 容 灾 复 制 功 能 ， 但 在 功能 上 却 没有 那么 强大 ， 属 于 轻 量 级 的 应 用 。 然 而 ， 因 为 架构 的 简单 ， 所 以 形式 更 趋 于 多 样 


化 。 


先 来 看 一 下 复制 代理 的 基本 特征 : 


“ 复制 代理 是 一 种 基于 事务 日 志 的 复制 ， 即 通过 在 线 日 志 的 应 用 来 实现 复制 功能 ， 而 非 简单 的 基于 SQL 语句 的 复制 ; 


“ 复制 代理 是 通过 TCP/IP 流 套 接 (Stream Socket) 收发 更 新 信息 ; 


“ 复制 代理 也 可 以 像 Data Guard 一 样 ， 选 择 同步 复制 或 异步 复制 的 模式 ; 


“ 复制 的 粒度 精细 到 日 志 的 时 间 戳 ， 有 效 解决 了 更 新 版 本 冲突 的 问题 。 


再 来 看 一 下 常见 的 复制 形式 ( 见 图 6-4) ，TimesTen 基 于 复制 技术 的 高 可 用 架构 可 分 为 : 主 从 复制 、 双 主 复制 、 环 形 复制 、 衍 生 复制 四 种 。 


主 从 复制 衍生 复制 


图 6-4 ”高 可 用 复制 模式 


然而 ， 在 TimesTen 数 据 库 的 架构 设计 上 ， 我 们 还 是 要 秉承 简单 快捷 的 原则 ， 这 在 一 定 程度 上 可 以 参考 MySQL 复 制 的 设计 ， 昌 然 可 以 选择 的 方式 很 多 ， 但 需要 选择 和 使 用 最 简单 、 最 不 容易 出 错 、 最 容 
易 排 错 的 方式 。TimesTen 本 身 就 是 轻 量 级 的 ， 简 单 至 上 ， 我 们 不 能 期 望 其 能 像 Oracle 一 样 强 大 。 因 此 ， 这 里 推荐 主 从 复制 方式 ， 通 常 应 用 的 要 求 基本 上 都 能 满足 。 
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开始 使 用 


通过 6.1 节 的 基础 概念 和 技术 架构 的 介绍 ， 我 们 对 TimesTen 内 存 数据 库 已 经 能 建立 起 一 套 完整 的 概念 体系 了 ， 接 下 来 将 展开 阐述 TimesTen 的 具体 操作 和 使 用 方法 ， 正 式 进 入 到 TimesTen 内 存 数 据 库 的 
世界 里 。 
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TimesTen 安 装 


一 切 操作 从 安装 配置 开始 ， 因 为 不 同 操作 系统 平台 的 安装 方法 可 能 存在 一 定 的 差异 。 在 本 例 中 ， 我 们 以 Linux 平 台 作为 实例 来 展示 。 


1.0S 用 户 与 组 创建 


使 用 操作 系统 root 用 户 来 创建 TimesTen 的 用 户 和 组 ， 用 户 名 为 ttalex， 组 名 为 ttadmin， 作 为 TimesTen 数 据 库 的 管理 和 操作 用 户 ， 并 创建 /etc/TimesTen 目 录 ， 用 于 日 志文 件 的 存储 。 


# 可 
# u 


roupadd ttadmin 
seradd -d /app/oracle/ttalex -g ttadmin -G ttadmin ttalex 


# mkdir /etc/TimesTen 


# 
# 
# 


hgrp -R ttadmin /etc/TimesTen 
hmod 770 /etc/TimesTen/ 
hmod 660 /etc/TimesTen/* 


设置 用 户 ttalex 的 环境 变量 ,修改 .bash_profile 文 件 如 下 : 


export ORACLE HOME=/app/oracle/11g/11.2.0.3.2 

export TNS ADMIN=$ORACLE HOME/network/admin 

export TT HOME=/app/oracle/ttalex/TimesTen 

LD LIBRARY PATH=$TT HOME/1ib:$ORACLE HOME/1ib:$LD LIBRARY PATH 
export LD LIBRARY PATH 加 
export PATH=$TT HOME/bin SORACLE HOME/bin :$PATH: $HOME /bin 


2. 内 核 参 数 配 置 


(1) 共享 内 存 设置 


1) kernel.shmmax: 单个 共享 内 存 段 的 最 大 值 ， 该 值 的 单位 为 字 节 。 


Timesten 实 例 需要 一 个 独立 的 共享 内 存 段 ， 所 以 该 值 需要 大 于 等 于 分 配给 Timesten 实 例 的 总 内 存 大 小 (包括 TimesTen 的 Data Store、 日 志 缓存 、 临 时 数据 等 ) 。 如 下 所 示 ， 该 段 内 存 区 域 可 以 在 参数 
配置 中 将 其 锁定 ， 不 被 交换 释放 : 


es Shared Memory Segments -------—- 
key Shmi owner perms bytes nattch status 
0x100d0272 1070137842 ttalex 660 61492690944 1 locked 


2) kernel.shmall: 所 有 共享 内 存 段 的 总 页 数 。 
该 参数 的 值 应 该 大 于 等 于 ceil (SHMMAX/PAGE_SIZE) 。Linux 系 统 中 的 PAGE_SIZE 值 ， 在 x86 平 台 上 为 4KB， 在 IA 平 台 上 为 16KB。 


若 需要 在 x86 平 台 上 创建 100GB 的 TimesTen 实 例 ， 以 上 两 个 参数 可 作 如 下 设置 : 


kernel.shmmax = 107374182400 
kernel.shmall = 26214400 


(2) 信号 量 设置 
1) kernel.sem， 分 别 对 应 以 下 四 个 信号 量 : 

“ SEMMSL: 每 个 信号 对 象 集 的 最 大 信号 对 象 数 ， 该 参数 决定 了 TimesTen 的 最 大 可 连接 数 ， 其 中 155 是 Timesten 内 部 使 用 ， 如 该 参数 设置 为 655， 则 表示 可 同时 接收 500 个 连接 数 ; 
“ SEMMNS: 系统 范围 内 最 大 信号 对 象 数 ，SEMMNS= (SEMMSL*SEMMNI) ; 

“ SEMOPM: 每 个 信号 对 象 支持 的 最 大 操作 数 ; 

“ SEMMNI: 系统 范围 内 最 大 信号 对 象 集 数 。 

(3) Huge Page 的 设置 

“ vm.nr_hugepages: 系统 中 配置 的 Huge Page 页 的 数量 。 


“Vm.hugetlb_shm_group: 系统 允许 创 建 共享 内 存 段 的 用 户 组 。 


如 果 需 要 创建 一 个 100GB 的 TimesTen 实 例 ， 且 Huge Page 大 小 为 2MB， 那 么 可 以 如 下 设置 ， 其 中 50188 为 相应 用 户 组 的 id 号 : 


wm.nr_ hugepages = 51200 
wm.hugetlb shm _ group = 50188 


配置 完成 后 可 以 如 下 进行 验证 : 


# cat /proc/meminfo | grep Huge 
HugePages Total: 51200 
HugePages Free: 51200 
HugePages Rsvd: 0 
Hugepagesize: 2048 kB 


(4) 复制 与 缓存 相关 设置 


如 果 TimesTen 数 据 库 需要 使 用 复制 代理 或 缓存 代理 功能 ， 我 们 还 需要 设置 一 些 网 络 相关 的 内 核 参数 ， 如 下 为 Oracle 推 荐 设置 。 在 实际 使 用 中 ， 还 是 需要 根据 具体 场景 和 规范 进行 必要 的 修改 。 


net.ipv4.tcp rmem = 4096 4194304 4194304 
net.ipv4.tcp wmem = 98304 4194304 4194304 
net .core.rmem default = 65535 

net .core.wmem default = 65535 
net.core.rmem max = 4194304 

net .core.wmem max = 4194304 
net.ipv4.tcp window scaling = 1 


3. 软 件 安装 


如 果 需 要 将 TimesTen 作 为 Oracle 的 缓存 来 使 用 ， 也 就 是 说 需要 使 用 缓存 代理 功能 ， 则 在 TimesTen 软 件 安装 之 前 ， 要 先 安装 Oracle 数 据 库 的 客户 端 ， 并 成 功 配置 连接 。 需 要 注意 的 是 ，Oracle 数 据 库 客 
户 端的 安装 和 TimesTen 软 件 的 安装 最 好 不 要 使 用 同一 用 户 来 进行 。 


接 下 来 将 开始 TimesTen 软 件 的 安装 过 程 。 


步骤 1 下 载 TimesTen 的 安装 包 到 指定 目录 ， 并 解压 。 


步骤 2 ”开始 安装 ， 与 Oracle 不 同 ，TimesTen 的 安装 只 需 简单 在 Shell 界 面 即 可 完成 。 


$ ./setup.sh 


步骤 3 ”交互 安装 过 程 开始 ， 先 确定 是 否 主机 上 已 经 存在 TimesTen 的 实例 。 如 果 主 机 是 第 一 次 安装 ， 则 会 有 如 下 提示 ， 直 接 输 入 新 建 实例 名 称 即 可 。 


Please choose an instance name for this installation? [ tt1122 ] ttalex 
Instance name will be 'ttalex'. 


Is this correct? [ yes ] 


如 果 主 机 上 已 存在 TimesTen 实 例 ， 则 会 提示 选择 是 新 建 、 升 级 还 是 查看 ， 此 处 选择 : “[1]Install a new instance” 进 行 实例 新 建 。 


There are 2 TimesTen instances installed locally : 
1) tt1122 (TimesTen11.2.2.5.0) 
2) tttest (TimesTen11.2.2.5.0) 
Of the following options : 
[1] Install a new instance 
[2] Upgrade an existing instance 
[3] Display information about an existing instance 
[q] Quit the installation 
Which would you like to perform? [ 1] 


Please choose an instance name for this installation? [ ] ttalex 
Instance name will be 'ttalex'. 
Is this correct? [ yes ] 


步骤 4 安装 类 型 ， 此 处 选择 : “[1]Client/Server and Data Manager”， 进 行 完 整 安装 。 


Of the three components: 
[1] Client/Server and Data Manager 
[2] Data Manager Only 
[3] Client Only 

Which would you like to install? [ 11] 


步骤 5 安装 路 径 ， 此 处 推荐 选择 : “[3]Specify a location” 自 定义 路 径 ， 并 指定 安装 路 径 为 “/app/oracle/ttalex”， 而 主 进程 与 日 志 安 装 目 录 默 认 即 可 。 


Of the following options : 

[1] /app/oracle/ttalex 

[2] /app/oracle/ttalex 

[3] Specify a location 

[gq] Quit the installation 
Where would you like to install the ttalex instance of TimesTen? [ 1]3 
Please specify a directory to install TimesTen? [ /app/oracle/ttalex ] /app/oracle/ttalex 
Where would you like to create the daemon home directory? [ /app/oracle/ttalex/ 

TimesTen/ttalex/info ] 

The daemon logs will be located in /app/oracle/ttalex/TimesTen/ttalex/info 
Would you like to specify a different Location for the daemon logs? [ no ] 
Installing into /app/oracle/ttalex/TimesTen/ttalex http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/... 
Uncompressing http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/... 


步骤 6 输入 主 进程 端口 ， 默 认 值 为 53396， 此 处 自 定义 选择 端口 为 53355。 


The default port number is 53396. 
Please enter a unique Port number for the TimesTen daemon (<CR>=list)? [ ] 53355 


步骤 7 "” 受 限 会 话 连 接 和 PL/SQL 功 能 均 进 行 默认 选择 。 


Restrict access to the the TimesTen installation to the group 'ttadmin'? [ yes ] 
Would you like to enable PL/SQL for this instance? [ yes ] 


步骤 8 ”缓存 代理 的 TNS 连 接 配置 采用 默认 连接 即 可 ( 需 预 先 安装 Oracle 客 户 端 。 


TNS_ ADMIN exists in your environment and is set to : 
/app/oracle/11g/11.2.0.3.2/network/admin 
Would you like to use this TNS ADMIN setting for the In-Memory Database Cache? [ yes ] 
TNS ADMIN will be set to /app/oracle/11g/11.2.0.3.2/network/admin 
You can change TNS ADMIN later by running <install dir>/bin/ttmodinstall. 
Installing server components http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/... 


步骤 9 ”输入 监听 端口 ， 默 认为 主 进程 端口 号 加 1， 采 用 默认 即 可 。 


What is the TCP/IP Port number that you want the TimesTen Server to listen on? [ 53356 ] 


步骤 10 ”其 他 安装 配置 过 程 均 如 下 采用 默认 值 。 


Do you want to install QuickStart and the TimesTen Documentation? [ no ] 
Would you like to install the documentation (without QuickStart)? [ yes ] 
Where would you like to create the doc directory (s=skip)? [ /app/oracle/ttalex/ 
TimesTen/ttalex/doc ] 
The TimesTen documentation has been installed in /app/oracle/ttalex/TimesTen/ttalex/doc. 
Installing client components http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/... 
Would you like to use TimesTen Replication with Oracle Clusterware? [ no ] 
Run the 'setuproot' script : 
cd /app/oracle/ttalex/TimesTen/ttalex/bin 
./setuproot -install 
This will move the TimesTen startup script into its appropriate location. 
The startup Script is currently located here : 
'/app/oracle/ttalex/TimesTen/ttalex/startup/tt ttalex'. 
The 11.2.2.5 Release Notes are located here : 
'/app/oracle/ttalex/TimesTen/ttalex/README.html’' 
Starting the daemon http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/... 
TimesTen Daemon startup OK. 
End of TimesTen installation. 


至 此 ，TimesTen 软 件 的 安装 已 经 完成 ， 同 时 Daemon 进 程 也 已 经 按照 默认 设置 开启 了 ， 接 下 来 将 进行 相关 参数 配置 的 介绍 。 


6.2.2 参数 配置 


参数 配置 对 于 任何 数据 库 来 说 都 是 必 不 可 少 的 ， 往 往 也 直接 关乎 到 使 用 效果 。 下 面 我 们 将 展开 介绍 TimesTen 内 存 数据 库 的 一 遇 


1.Daemon 人 参数 配置 


进行 Daemon 参 数 的 配置 ， 需 要 编辑 4$TT_ HOME/info/ttendaemon.options 文 件 ， 用 户 可 根据 需要 进行 合理 配置 ， 相 关 配 置 参数 如 表 6-1 所 示 。 


表 6-1 ”Daemon 选项 参数 说 明 


参 数 默认 值 
supportlog 警告 日 志文 件 的 路 径 和 文件 名 $TT HOME/info/ttmesg.log 
maxsupportlogfiles 在 线 日 志文 件数 闽 值 ， 超 出 会 自动 清理 10 
maxsupportlogsize 在 线 日 志文 件 大 小 10485760 
userlog 错误 日 志文 件 的 路 径 和 文件 名 $TT HOME/info/tterrors.log 

( 续 ) 

参 数 说 明 默认 值 
maxuserlogfiles 错误 日 志文 件数 国 值 ， 超 出 会 自动 清理 10 
maxuserlogsize 错误 日 志文 件 大 小 0x100000 
Verbose 显示 详细 信息 设置 
tns admin TNS 文件 路 径 安装 过 程 设置 值 
server CS 连接 模式 下 连接 端口 号 安装 过 程 设置 值 
linuxLargePageAlignment Huge Page 的 大 小 ， 单 位 为 MB 2 
showdate 志文 件 中 显示 日 期 不 设置 


中 


通常 情况 下 ， 只 需要 按照 默认 参数 配置 即 可 ， 重 启 Daemon 进 程 以 使 得 配置 生效 。 


$ ttdaemonadmin -restart 
TimesTen Daemon stopped. 
TimesTen Daemon startup OK. 


2. 常 用 实例 参数 配置 


在 开始 创建 TimesTen 实 例 之 前 ， 需 要 先 配置 TimesTen 的 实例 参数 文件 : sys.odbc.ini， 该 文件 位 于 $TT_HOME/info 目 录 下 。 其 中 ， 重 要 的 参数 如 表 6-2 所 示 ， 根 据 需 求 个 性 化 定制 ， 通 常情 况 取 默 认 值 
即 可 。 


表 6-2 常用 实例 参数 说 明 


参 数 上 默认 值 
类 所 | 床 字符 集 : Or 绥 存 疆 
DatabaseCharacterset _ 数据 振子 香 集 ， 人 Oracle 缓存 时 ， 
需 与 Oracle 保持 一 致 
DataStore Data Store 的 路 径 ， 设 置 后 不 能 被 修改 
LogDir 在 线 日 志文 件 的 存放 路 径 默认 与 数据 文件 相同 路 径 
在 数据 库 创 建 时 是 否 预先 分 配 磁盘 |0: 否 (默认 ) 
Preallocate ee 
空间 ] : 是 
使 用 T 树 索引 或 B 树 索 引 ， 设 置 后 |0: B-tree 索引 (默认 ) 
RangeIndexType A a 
不 能 被 修改 1: T-tree 索引 | 
语法 和 数据 类 型 是 遵从 Oracle 规则 | 0: Oracle 规则 (默认 ) 
TypeMode a 有 . 
还 是 TimesTen 规则 1: TimesTen 规则 
0: 自动 并 行 复制 (默认 ) 
ReplicationApplyordering | 复制 应 用 日 志 的 顺序 站 
1: 用 户 上 日 定义 并 行 
, ro os se 默认 值 : 1 
ReplicationParallelism 复制 时 的 并 行 度 ， 根 据 CPU 能 力 选 择 


取 值 范围 : [1, 32] 
PermSize Data Store 内 存 大 小 ， 设 置 后 只 能 改 大 | 默认 值 : 32MB 
临时 数据 内 存 的 大 小 
如 果 PermSize < 64 MB: 
TempSize TempSize = 32 + ceil(PermSize/4) 


售 则 : 


TempSize = 40 + ceil(PermSize/8) 


( 续 ) 
参 数 默认 值 
: 默认 值 : MIN(2000, SEMMSL) 
Connections a 
取 值 范围 : [1. 2000] 
LogBufMB 日 志 缓 存 内 存 大 默认 值 : 64 (M) 
默认 值 : 4 
LogBufParallelism 写 日 志 缓 存 的 并 行 度 Sr 
写 日 志 缓 存 的 并 行 度 取 值 范围 ，[1. 64] 
LogFileSize 在 线 日 志文 件 大 小 默认 值 : 64 (M) 
0: 不 自动 清除 
LogPurge 是 耕 自 动 清除 过 期 的 日 志文 件 ee 
合 目 清除 过 明 的 日 圭 文件 1 自动 清除 (默认 ) 
CkptFrequency 两 次 检 ll 默认 值 : 600 秘 
ri 丛 桂 = EE 多 少 ; 长 增 _ 
CkptLogVolume EO i 默认 值 : 0， 表 示 忽 视 该 参数 
CkptRate 每 秒 钟 检查 点 的 最 大 类 默认 值 0， 表 示 不 限制 
0 (默认 ): 不 锁定 
1: 加 载 时 锁定 ， 锁 定 失败 允许 连接 
MemoryLock 是 否 将 Data Store 锁定 在 物理 内 存 中 |2: 加 载 时 锁定 ,锁定 失败 不 可 连接 
3: 持续 锁定 ,锁定 失败 允许 连接 
4: 持续 锁定 ， 锁 定 失败 不 可 连接 
. 复制 过 程 中 ， 接 收 节点 的 线程 数 , | 默认 值 : 
ReceiverThreads a i 
多 CPU 节点 可 以 设置 为 2 取 值 范围 : [1, 2] 
默认 值 : 1 
RecoveryThreads Data Store 恢复 时 ， 重 建 索引 线程 数 Ne 
ata Store 恢复 时 ， 重 建 案 引 线程 取 值 范围 : 1 ~ CPU_COUNT 
i 志 到 磁盘 文件 的 | 0: 异步 写 日 志 (默认 值 ) 
DurableCommits 
1: 同步 写 日 志 
0: serializable 
Isolation 务 隔离 级 别 ， 与 Oracle 一 致 
事务 隔离 级 别 ， 与 Oracle 1: read committed (默认 值 ) 
、 0; 行 级 别 锁 (默认 值 ) 
yp 锁 级 别 行 级 别 锁 (默认 值 
1: 数据 库 级别 锁 
LockWait 锁 等 待 时 间 默认 值 : 10 秒 


OracleNetServiceName 


连接 Oracle 的 TNS 


需要 注意 的 是 ，TimesTen 实 例 参数 类 似 于 Oracle 的 pfile， 不 能 被 实例 动态 加 载 ， 修 改 后 需要 重启 数据 库 后 生效 。 以 上 未 能 提 及 的 参数 说 明 ， 可 以 参考 TimesTen 数 据 库 的 官方 文档 。 


6.2.3 ”创建 独立 实例 


当 完 成 Daemon 的 参数 配置 和 实例 参数 配置 之 后 ， 我 们 接 下 来 就 可 以 开始 创建 TimesTen 的 实例 了 。 


对 于 TimesTen 来 说 ， 它 可 以 是 独立 存在 的 数据 库 ， 也 可 以 是 Oracle 数 据 库 的 缓存 。 但 是 ， 不 论 如 何 使 用 ,我 们 都 将 先 创 


建 一 个 TimesTen 独 立 的 实例 。 具 体 步骤 如 下 : 


步骤 1 ”首次 连接 ttalex 数 据 库 实例 ， 如 下 ， 可 以 通过 ttlsql 命 令 进行 实例 连接 。ttalex 实 例 的 参数 配置 已 经 完成 ， 当 发 起 首次 连接 的 时 候 ，TimesTen 会 自动 完成 各 类 文件 的 创建 和 内 存 段 的 开辟 。 


$ ttIsql ttalex 

Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights reserved. 
Type ? or "help" for help, type "exit" to quit ttIsql。 

connect "DSN=ttalex"; 

Connection successful: DSN=ttalex;UID=ttalex;..... 
PermSize=512;TempSize=100;PermWarnThreshold=80;TempWarnThreshold=80;..... 
(Default setting AutoCommit=1) 

Command> select user from dual; 

< TTALEX > 


通过 以 上 “ttlsql ttalex” 命 令 连接 实例 时 ， 我 们 可 以 视 作 是 sysdbaf 
默认 设置 。 


户 本 地 验证 的 连接 方式 ， 此 连接 用 户 与 实例 同名 ， 


步骤 2 ”按照 步骤 1 创建 的 实例 默认 为 随 Daemon 启 动 而 自动 加 载 ， 


为 TTALEX。 当 连接 成 功 后 ， 会 提示 实例 的 初始 化 参数 设置 情况 ， 


需要 修改 一 下 其 加 载 策略 ， 使 其 为 手工 加 载 方式 ， 并 手工 加 载 实 例 ， 如 下 所 示 。 


没有 显示 的 为 


$ ttAdmin -ramPolicy manual ttalex 


RAM Residence Policy : manual 
Manually Loaded In RAM : False 
Replication Agent Policy : manual 
Replication Manually Started : False 
Cache Agent Policy : manual 
Cache Agent Manually Started : False 
$ ttAdmin -ramLoad ttalex 

RAM Residence Policy : manual 
Manually Loaded In RAM ; True 


Replication Agent Policy : manual 


Replication Manually Started ; False 
Cache Agent Policy : manual 
Cache Agent Manually Started ; False 


步骤 3 创建 一 个 TimesTen 的 用 户 alextt， 并 赋予 admin 权 限 ， 作 为 DBA 管 理 用 户 。 此 时 ，TimesTen 的 独立 实例 就 算 完成 了 。 可 以 使 用 新 建 的 DBA 用 户 alextt 进 行 数据 库 连接 ， 并 创建 数据 表 。 


$ ttIsql ttalex 

Command> create user alextt identified by alextt; 
User created. 

Command> grant admin to alextt; 

$ ttIsql "DSN=ttalex;UID=alextt;PWD=alextt;" 
Command> create table alex t601 (id number, name varchar2(100)); 
Command> insert into alex t601 values (1, 'alex'); 
1 row inserted. 加 

Command> ;insert into alex t601 values (2, 'alex'); 
1 row inserted. a 

Command> commit; 

Command> select * from alex 七 6017 

< 1, alex > 

< 2, alex > 

2 rows found. 


6.2.4 创建 缓存 实例 


如 果 该 TimesTen 实 例 将 用 作 Oracle 数 据 库 的 缓存 ， 那 么 还 要 进行 接 下 来 的 配置 ， 在 Oracle 端 和 TimesTen 端 建立 连接 ， 并 配置 心跳 。 其 实 ， 所 谓 的 缓存 实例 就 是 在 独立 实例 的 基础 上 ， 追 加 Oracle 缓 存 


的 功能 。 


本 质 上 来 说 ， 不 论 是 Oracle 到 TimesTen 的 刷新 ， 还 是 TimesTen 到 Oracle 的 刷新 ， 其 操作 发 起 方 都 是 TimesTen，Oracle 都 是 在 响应 TimesTen 的 操作 。 因 此 ， 在 进行 TimesTen 配 置 之 前 ， 需 要 先 在 


Oracle 数 据 库 端 进 行 相应 配置 ， 以 允许 TimesTen 对 Oracle 数 据 库 的 操作 。 


在 Oracle 数 据 库 进行 TimesTen 的 初始 化 配置 ， 可 按 如 下 步骤 : 


步骤 1 创建 一 个 新 的 表 空间 TTSPACE， 用 于 存储 TimesTen 的 数据 字典 表 ， 并 使 用 TimesTen 自 带 的 脚本 initCacheGlobalSchema.sql 进 行 表 空间 的 初始 化 配置 ， 完 成 后 会 自动 在 Oracle 数 据 库 上 创建 


一 个 名 为 TimesTen 的 用 户 ， 但 需 将 默认 密码 修改 掉 。 


$ sqlplus "sys@alex as sysdba" 
SQL> @$TT HOME/oraclescripts/initCacheGlobalSchema.sql "TTSPACE" 
SQL> alter user timesten identified by <new password>; 


步骤 2 新 建 数据 同步 cacheuser， 通 过 脚本 grantCacheAdminPrivileges.sql 进 行 用 户 授 权 。 


SQL> create user cacheuser identified by cacheuser default tablespace; 
SQL> alter user cacheuser quota unlimited on users; 
SQL> Q@$TT HOME/oraclescripts/grantCacheAdminPrivileges.sql "cacheuser" 


完成 Oracle 端 的 初始 化 配置 之 后 ， 接 下 来 将 要 在 TimesTen 端 再 进行 一 下 初始 化 的 配置 工作 。 具 体 步骤 如 下 。 


步骤 3 在 TimesTen 端 新 建 数据 同步 用 户 cacheuser 和 Oracle 数 据 库 对 应 业务 用 户 alex， 需 注意 最 小 化 权限 控制 。 然 后 ， 调 用 内 置 存储 过 程 ttCacheUidPwdSet 在 TimesTen 端 设置 Oracle 连 接 的 用 户 名 


和 密码 。 


Command> create user cacheuser identified by cacheuser; 
Command> grant create session, cache manager to cacheuser; 
Command> grant create any table to cacheuser; 

Command> create user alex identified by alex; 

Command> call ttCacheUidPwdSet ('cacheuser', 'cacheuser'); 


步骤 4 切换 到 cacheuser 用 户 连接 (注意 在 连接 参数 中 添加 oraclePWD 来 指定 Oracle 连 接 用 户 密码 ) ， 创 建 名 为 myGrid 的 缓存 网 格 (Cache Grid) ， 用 于 关联 多 实例 并 行 的 TimesTen 数 据 库 架构 ， 


有 些 类 似 于 Oracle 的 RAC 架 构 ， 我 们 将 在 6.4.2 节 中 具体 展开 网 格 的 特性 介绍 。 该 操作 是 连接 到 Oracle， 进 行 相应 数据 字典 表 的 创建 ， 在 Oracle 端 使 用 cacheuser 用 户 可 以 查询 到 相关 表 信 息 。 


$ttIsql "DSN=ttalex;UID=cacheuser; PWD=cacheuser;OraclePWD=cacheuser" 
Command> call ttGridCreate('myGrid'); 
Command> call ttGridNameSet ('myGrid'); 
SQL> select table name from user tables 
2 where table name like '%MYGRIDS'; 
TABLE NAME 轩 
TT _06 MYGRID 1CGNODEID 
TT 06 MYGRID 1CGNODEINFO 
TT_06 MYGRID 1CGGROUPDEFS 


在 TimesTen 的 架构 中 ， 默 认 情况 下 任何 实例 都 必须 隶属 于 一 个 缓存 网 格 ， 但 是 对 于 单 实例 的 TimesTen 应 用 来 说 ， 缓 存 网 格 也 可 以 不 创建 的 ， 修 改 实例 参数 CacheGridEnable， 使 其 忽视 该 限制 。 当 
创建 一 个 缓存 网 格 对 于 单 实例 应 用 也 没有 什么 坏处 。 


至 此 ，TimesTen 的 缓存 实例 创建 就 完成 了 。TimesTen 实 例 可 以 用 作 于 独立 的 数据 库 ， 也 可 以 用 作 于 Oracle 数 据 库 的 前 置 缓存 。 


6.3 ”缓存 集合 管理 


户 ， 


完成 了 缓存 实例 的 创建 ， 是 否 就 可 以 立刻 实现 Oracle 和 TimesTen 的 数据 同步 呢 ? 答案 是 否定 的 ， 我 们 还 需要 在 TimesTen 数 据 库 中 创建 相关 的 缓存 集合 (Cache Group) 。 


[ 


那 什么 是 缓存 集合 呢 ? 需要 被 缓存 到 TimesTen 数 据 库 里 的 Oracle 数 据 库 的 数据 集合 ， 称 之 为 缓存 集合 。 如 图 6-5 所 示 ，Oracle 数 据 库 中 业务 表 属 主 用 户 为 alex， 在 TimesTen 内 存 数据 库 中 存在 同名 
其 为 业务 缓存 表 属 主 ， 相 应 缓存 集合 会 建立 在 cacheuser 属 主 用 户 下 ， 该 用 户 下 可 以 存在 多 个 缓存 集合 ， 每 个 缓存 集合 可 以 包含 一 张 或 多 张 存在 关联 关系 的 Oracle 对 应 表 ， 但 每 个 缓存 集合 中 有 且 只 有 


一 张 父 表 (Root Table) ， 以 及 若干 与 之 关联 或 相互 关联 的 子 表 (Child Table) 。 


Load 
Refresh 
AutoRefresh 


Flush 


Propagate 
cacheuser 


cacheuser 


业务 表 缓 存 组 


业务 表 缓 存 组 


订单 明细 表 


图 6-5 ”缓存 集合 架构 图 


Oracle 与 TimesTen 之 间 的 数据 刷新 是 通过 Oracle 端 业务 表 和 TimesTen 端 缓存 集合 的 交互 来 实现 的 ， 从 Oracle 端 到 TimesTen 端 的 刷新 有 以 下 三 种 方式 : 
“加载 (Load) 

:刷新 (Refresh) 

“ 自动 刷新 (AutoRefresh) 

对 于 增 量 刷新 的 模式 ， 在 Oracle 数 据 库 端 ， 每 个 业务 表 上 都 会 有 一 个 触发 器 记录 该 表 上 的 数据 变化 ， 并 记录 到 TimesTen 的 数据 字典 表 中 ， 按 照 刷 新 策略 刷新 到 TimesTen 的 缓存 集合 中 。 
而 从 TimesTen 端 刷新 数据 到 Oracle 端 ， 则 可 以 通过 以 下 两 种 方式 同步 或 异步 地 来 实现 : 

“ 冲洗 (Flush) 


“ 衍化 (Propagate) 


根据 缓存 集合 不 同 的 作用 ， 我 们 可 以 将 缓存 集合 分 为 以 下 四 种 类 型 : 


“只 读 缓 存 集合 (Read only Cache Group) ; 


“ AWT 缓 存 集合 (Asynchronous Writethrough Cache Group) ; 
“ SWT 缓 存 集合 (Synchronous Writethrough Cache Group) ; 


' 自 定义 缓存 集合 (Usermanaged Cache Group) 。 


不 同类 型 的 缓存 集合 的 数据 刷新 方式 也 是 不 一 样 的 ， 每 一 种 缓存 集合 都 是 有 其 特有 的 刷新 方式 的 ， 具 体 情 况 如 表 6-3 所 示 。 


表 6-3 ”缓存 集合 刷新 方式 


级 存 集合 支持 
新式 | 

目 标 只 读 AWT SWT 自 定义 
Popgate | Te | one | | YY | YY | > 


在 本 节 接 下 来 的 内 容 中 ,我 们 将 详细 展开 这 四 种 缓存 集合 的 特性 介绍 。 


6.3.1 “只 读 缓存 集合 


首先 来 看 一 下 只 读 缓存 集合 (Read only Cache Group) ， 顾 名 思 义 ， 对 于 TimesTen 数 据 库 来 说 ， 它 是 一 个 只 读 的 缓存 集合 ， 其 包含 的 业务 缓存 表 对 TimesTen 来 说 是 不 支持 写 操作 的 ， 所 有 的 数据 变 
化 都 是 从 Oracle 端 刷新 过 来 的 。 它 的 主要 特性 包括 : 


“ 每 隔 一 定时 间 ， 缓 存 代 理 将 数据 从 Oracle 刷 新 到 TimesTen 中 ; 


: 适用 于 储存 几乎 没有 更 新 的 数据 ; 


“ 能 保证 单一 数据 库 源 的 写 入 ， 能 更 好 地 控制 数据 一 致 性 ， 重 点 推荐 。 


只 读 缓存 集合 仅 支 持 单 向 的 数据 刷新 ， 看 似 没有 太 大 应 用 价值 ， 但 却 是 TimesTen 缓 存 Oracle 的 经 典 应 用 方式 。 一 方面 ， 可 以 将 Oracle 数 据 库 中 高 并 发 争 用 压力 较 大 的 查询 业务 分 离 到 TimesTen， 实 现 
读 写 分 离 和 压力 分 担 ; 另 一 方面 ， 数 据 全 量 被 保存 在 Oracle 中 ， 降 低 了 数据 丢失 和 不 一 致 的 风险 。 


1. 创 建 只 读 缓存 集合 


下 面 我 们 将 新 建 一 个 只 读 缓存 集合 ， 通 过 实例 来 具体 了 解 一 下 其 特性 。 具 体 步骤 如 下 : 


步骤 1 在 Oracle 端 的 alex 用 户 下 新 建 一 个 测试 用 表 tt_readonly 601， 并 初始 化 5 行 记录 。SQL 语 句 如 下 所 示 : 


SQL> create table alex.tt readonly 601 (id number primary key, 
2 name varchar2(100)); 
SQL> grant select on alex.tt readonly 601 to cacheuser; 


SQL> insert into alex.tt readonly 601 values (1, 'a') 
SQL> insert into alex.tt readonly 601 values (2, 'b 
SQL> insert into alex.tt readonly 601 values (3, 'c' 
SQL> insert into alex.tt readonly 601 values (4, 'd 
SQL> insert into alex.tt readonly 601 values (5, 'e 


SQL> commit; 


步骤 2 ”在 TimesTen 端 ， 使 用 cacheuser 用 户 新 建 表 tt_readonly_601 对 应 的 只 读 缓存 集合 cg_readonly 601， 并 可 以 通过 “cachegroup cg_readonly 601” 命 令 查 询 该 缓存 集合 的 状态 。 示 例如 下 所 
示 ， 可 以 看 到 默认 情况 下 ， 只 读 缓 存 集合 采用 了 增 量 自动 刷新 模式 ， 但 是 并 未 开启 ， 为 暂停 状态 ， 刷 新 频率 为 5 分 钟 一 次 。 


$ttIsql "DSN=ttalex;UID=cacheuser; PWD=cacheuser;OraclePWD=cacheuser" 
Command> call ttCacheStart; 
Command> create readonly cache group cacheuser.cg readonly 601 
from alex.tt readonly 601 (id number primary key, 
> name varchar2(100)); 

Command> cachegroup cg readonly 601; 
Cache Group CACHEUSER.CG READONLY 601: 

Cache Group Type: Read Only 

Autorefresh: Yes 

Autorefresh Mode: Incremental 

Autorefresh State: Paused 

Autorefresh Interval: 5 Minutes 

Autorefresh Status: ok 

Aging: No aging defined 

Root Table: ALEX.TT READONLY 601 

Table Type: Read Only 加 


V 


此 时 ， 在 Oracle 端 的 源 表 tt_readonly_601 上 新 建 了 一 个 记录 DMI 操作 的 触发 器 TT_06_79317 T， 用 以 将 后 续 该 表 上 的 DMI 操作 记录 到 TimesTen 数 据 字典 表 中 ， 相 当 于 记录 操作 的 日 志 一 样 。 另 一 方 
面 ， 如 果 缓存 集合 设置 为 全 量 刷新 的 话 ， 是 不 会 创建 触发 器 的 。 


SQL> select * from dba triggers where table_cowner='RALEX'" 
2 and table name='TT READONLY 601'7 
OWNER TRIGGER_ NAME, TRIGGER_TYPE TRIGGERING EVENT 


CACHEUSER TT 06 79317 T AFTER EACH ROW INSERT OR UPDATE OR DELETE 


需要 注意 的 是 ， 对 于 增 量 自动 刷新 都 是 基于 以 上 触发 器 (只 支持 INSERT、UPDATE、DELETE) 来 进行 的 ， 是 不 允许 在 Oracle 端 进行 TRUCATE 操 作 的 ， 否 则 会 造成 数据 不 一 致 。 


与 此 同时 ， 在 cacheuser 用 户 下 ， 会 创建 一 个 与 源 表 对 应 的 操作 日 志 表 tt_06_79317_ 1， 记录 源 表 数据 变化 的 主键 信息 。 


SQL> select * from cacheuser.tt 06 79317 1; 


LOGSEQ FT_CRACHEGROUP ID XID 
6 0 21 10.25.7068 
6 0 22 10.25.7068 


步骤 3 ”在 TimesTen 端 进行 表 tt_readonly_ 601 的 数据 初始 化 ， 从 Oracle 端 全 量 加 载 到 TimesTen 数 据 库 ， 且 每 加 载 1 行 进行 一 次 提交 。 此 时 ，Oracle 的 5 行 记 录 都 加 载 到 TimesTen 中 ， 且 “Autorefresh 
State” 被 自动 设置 为 “On” 状态 。 示 例如 下 : 


Command> load cache group cacheuser.cg readonly 601 cormit every 1 rows; 
5 cache instances affected. 


Command> select * from alex.tt readonly 601; 
过 本 实 
< Di b> 
过- 也 区 
< da;d> 
必 5 各 
5 rows found. 
Command> cachegroup cg readonly 601; 
Cache Group CACHEUSER.CG READONLY 601: 
Cache Group Type: Read Only 
Autorefresh: Yes 
Autorefresh Mode: Incremental 
Autorefresh State: On 
Autorefresh Interval: 5 Minutes 
Autorefresh Status: ok 
Aging: No aging defined 
Root Table: ALEX.TT READONLY 601 
Table Type: Read Only 


默认 情况 下 ， 缓 存 集合 的 “Autorefresh Mode” 为 “Incremental”， 即 增 量 加 载 数据 ， 因 为 TimesTen 端 的 缓存 表 中 是 没有 数据 的 ， 当 初始 化 加 载 的 时 候 ， 实 际 上 进行 的 是 全 量 加 载 。 在 使 
居 量 较 大 的 表 来 说 。 如 果 是 一 些 数据 量 很 小 的 表 ， 可 以 设置 为 全 量 加 载 模式 ， 具 体 如 下 所 示 : 


于 


设置 为 全 量 加 载 是 不 明知 的， 将 带 来 非常 大 的 数据 库 压 力 和 网 络 压力 ， 特 别 是 对 数 折 


Command> alter cache group cacheuser.cg readonly 601 set 
> autorefresh mode full; 


Autorefresh 属 性 的 


体 说 明 如 下 。 


“ 更 新 模式 可 分 为 以 下 几 类 。 


“ FULL: 整体 更 新 缓存 ， 适 合 更 新 量 很 大 的 情况 ; 


“ INCREMENTAL (默认 ) : 仅 更 新 更 改过 的 数据 ， 适 合 更 新 量 很 小 的 情况 。 


“INTERVAL: 自动 更 新 的 时 间 间 隔 ， 默 认为 5 分 钟 。 


: STATE: 是 否 开 启 AUTOREFRESH 功 能 ， 默 认为 暂停 (PAUSE) 。 


步骤 4 修改 缓存 集合 的 刷新 频率 为 5 秒 钟 ， 再 于 Oracle 端 源 表 进 行 增 、 删 、 改 的 测试 ， 如 下 所 示 ，TimesTen 端 的 缓存 表 也 在 5 秒 钟 之 后 自动 刷新 了 ， 只 读 缓存 集合 创建 完成 。 


Command> alter cache group cacheuser.cg readonly 601 set 
> autorefresh interval 5 seconds; 

insert into tt readonly 601 values (11,'a'); 

delete from tt readonly 601 where id=4; 

update tt readonly 601 set name='bbb' where id=2; 
commit; 

Select * from tt readonly 601 order by id; 

ID NAME 


Command> select * from alex.tt readonly 601; 
过 二 千 突 

< 2, bbb > 

i 

<5,e> 

C11; 六 

rows found. 


2. 刷 新 方式 


前 面 提 到 ， 对 于 只 读 缓存 集合 来 说 ,数据 刷新 只 能 从 Oracle 端 刷新 到 TimesTen 端 ， 且 只 有 “Load”、 
“Load” 和 “Refresh” 则 是 需要 手工 触发 的 ， 其 与 “AutoRefresh” 有 什么 


过 程 为 自动 过 程 ， 不 需要 人 工 干 预 。 然 而 ， 


步骤 1 首先 需要 暂停 只 读 缓存 集合 的 自动 刷新 功能 : 


“Refresh”、 


“AutoRefresh” 三 种 方式 。 
区 别 呢 ? 我 们 通过 以 下 的 示例 来 看 看 吧 。 


其 中 ， 


“AutoRefresh” 的 方式 通过 缓存 集合 的 创建 


Command> alter cache group cacheuser.cg readonly 601 set 
> autorefresh state paused; 


步骤 2 ”在 Oracle 端 插入 两 条 新 的 记录 ， 成 功 完成 ， 但 并 未 自动 刷新 到 TimesTen 的 缓存 表 中 。SQL 语 句 如 下 所 示 : 


insert into tt readonly 601 values (21,'a'); 
insert into tt readonly 601 values (22,'b'); 
commit; 

select * from tt readonly 601 where id>20; 
NAME, 加 


22 b 
Command> select * from alex.tt readonly 601 where id>20; 
0 rows found. 


步骤 3 ” 当 于 TimesTen 端 通过 “Load” 方 式 手工 加 载 的 时 候 ， 发 现 报错 了 ， 


无 法 进行 加 载 。 如 果 缓 存 集合 为 只 读 的 时 候 ， 


“Load” 加 载 方式 只 能 


于 数据 的 初始 化 加 载 ， 报 错 示例 如 下 : 


Command> load cache group cacheuser.cg readonly 601 commit > every 
8288: Manual LOAD of cache group CACHEUSER.CG READONLY 601 is not 
allowed because it is specified as AUTOREFRESH and it is not empty 
The command failed. 


步骤 4 而 当 使 


100 rows; 


“Refresh” 方 式 进行 刷新 的 时 候 ， 发 现 是 成 功 的 。 然 而 ， 此 时 的 刷新 是 全 量 的 ， 共 有 7 行 记录 被 刷新 到 TimesTen 缓 存 表 ， 而 非 自 


动 刷新 设置 的 增 量 方式 ， 示 例如 下 : 


Command> refresh cache group cacheuser.cg readonly 601 commit 
> every 100 rows; 加 加 

7 cache instances affected. 

Command> select * from alex.tt readonly 601 where id>20; 

过 光 Ls 二 名 加 加 

< 227 b> 

2 rows found. 


从 根本 上 来 说 ， 


“Refresh” 操 作 是 先进 行 了 “Unload” 操 作 (相对 于 “Load” 来 说 的 ， 即 将 TimesTen 的 缓存 集合 清空 ) ， 再 进行 一 次 “Load” 操 作 。 对 于 只 读 缓存 集合 的 使 用 ， 尽 量 使 


旗 


刷新 模式 ， 非 必要 时 不 要 使 用 “Refresh” 的 全 量 刷 新 方式 。 


6.3.2 AWT 缓 存 集合 


接 下 来 看 一 下 AWT 缓 存 集合 (Asynchronous Writethrough Cache Group) 吧 。 与 只 读 缓存 集合 不 同 ， 不 论 是 对 于 Oracle 数 据 库 来 说 ， 还 是 TimesTen 数 据 库 ，AWT 缓 存 集合 都 是 可 读 写 的 ， 


Oracle 与 TimesTen 之 间 的 数据 刷新 是 可 以 双向 进行 的 。 它 的 主要 特性 包括 : 


Er 
师 ， 


' TimesTen 事 务 提 交 后 ， 触 发 到 Oracle 刷 新 数据 ， 其 操作 为 异步 写 入 ，DML 被 抛 给 Oracle， 不 等 待 Oracle 完 成 提交 ; 
“ 适用 于 希望 通过 TimesTen 加 速 DML 操 作 的 情况 ， 对 于 一 些 高 并 发 写 入 压力 较 大 的 业务 应 用 ， 可 以 使 用 该 缓存 集合 ， 并 异步 批量 刷新 到 Oracle 数 据 库 ， 避 免 了 Oracle 上 的 争 用 压力 ; 


“ 虽然 AWT 缓 存 集合 支 持 双向 刷新 ， 但 还 是 尽 可 能 只 在 TimesTen 单 一 数据 库 源 进 行 写 入 ， 保 证 数据 一 致 性 。 


值得 注意 的 是 ， 在 只 读 缓存 集合 中 ，Oracle 的 表 是 源 表 ，TimesTen 的 表 为 其 缓存 表 ; 而 在 AWT 缓 存 集合 中 ，TimesTen 的 表 为 源 表 ，Oracle 的 表 为 其 缓存 表 ， 主 刷新 方向 是 从 TimesTen 端 到 Oracle 
可 自动 完成 ， 所 不 同 的 是 ，AWT 缓 存 集合 也 是 能 支持 手工 触发 从 Oracle 到 TimesTen 反 向 刷新 的 。 


1. 创 建 AWT 缓 存 集合 


同样 ， 先 来 创建 一 个 AWT 缓 存 集合 ， 具 体 步 骤 如 下 : 


步骤 1 在 Oracle 端 的 alex 用 户 下 新 建 一 个 测试 用 表 tt_awt_601， 并 初始 化 3 行 记录 。SQL 语 句 如 下 所 示 : 


SQL> create table alex.tt awt 601 (id number primary key, 
2 name varchar2(100)); 

SQL> grant select on alex.tt awt 601 to cacheuser; 

SQL> insert into alex.tt awt 601 values (1, ‘a'); 

SQL> insert into alex.tt awt 601 values (2, 'b'); 

SQL> insert into alex.tt awt 601 values (3, 'c'); 

SQL> commit; 一， 


步骤 2 在 TimesTen 端 ， 使 用 cacheuser 用 户 新 建 表 tt_awt_601 对 应 的 AWT 缓 存 集合 cg_awt_601。 示 例如 下 所 示 ， 与 只 读 缓存 集合 不 同 ，AWT 缓 存 集合 是 不 支持 自动 刷新 设置 的 ， 也 就 无 所 谓 自动 刷 


新 的 全 量 和 增 量 之 分 ， 在 Oracle 端 就 不 会 创建 用 于 捕获 DML 操 作 的 触发 器 和 记录 DMI 行为 的 日 志 表 。 表 类 型 显示 的 “Propagate” ， 表 示 该 表 是 通过 衍化 的 方式 自动 刷新 数据 到 Oracle 端 的 。 


Command> create asynchronous Writethrough cache group 
> cacheuser.cg awt 601 
> from alex.tt awt 601 (id number primary key, 
> name varchar2 (100) ) 7 
Command> cachegroup cg awt 601; 
Cache Group CACHEUSER.CG AWT 601: 
Cache Group Type: Asynchronous Writethrough 
Autorefresh: No 
Aging: No aging defined 
Root Table: ALEX.TT AWT 601 
Table Type: Propagate 


步骤 3 在 TimesTen 端 ， 新 建 2 行 记 录 到 表 alex.tt_awt_601， 再 分 别 在 Oracle 端 和 TimesTen 端 进行 表 tt_awt_601 的 查询 。 如 下 示例 ， 我 们 惊奇 地 发 现 Oracle 和 TimesTen 在 各 行 其 道 ， 没 有 任何 的 刷 
如 下 所 示 ， 问 题 出 在 哪里 呢 ? 


Command> insert into alex.tt awt 601 values (4,'d'); 
1 row inserted. 

Command> insert into alex.tt awt 601 values (5,'e'); 
1 row inserted. 

Command> select * from alex.tt awt 601; 

< 4:d> Es 

汉 5 总 各 

SQL> select * from tt awt 601; 

ID NAME 


问题 出 在 没有 开启 复制 代理 。 只 读 缓存 集合 的 数据 刷新 是 通过 缓存 代理 从 Oracle 端 刷新 到 TimesTen 端 ， 而 AWT 缓 存 集合 则 需要 复制 代理 从 TimesTen 端 刷新 到 Oracle 端 。 复 制 代理 除 了 实现 TimesTen 


实例 之 间 的 数据 复制 外 ， 还 承担 了 AWT 缓 存 集合 的 数据 刷新 服务 。 此 时 ， 我 们 开启 复制 代理 ， 如 下 所 示 ，TimesTen 的 数据 将 即时 地 通过 衍化 (Propagate) 方式 刷新 到 Oracle 端 ， 但 Oracle 端 的 数据 不 会 


自动 刷新 到 TimesTen 端 。 


Command> call ttRepStart; 

Command> select * from alex.tt awt 601; 
<4,d> 

必 与 -总 信 

2 rows found. 

SQL> select * from alex.tt awt 601; 

ID NAME 


至 此 ， 我 们 通过 AWT 缓 存 集合 ， 轻 松 地 实现 了 TimesTen 到 Oracle 的 数据 刷新 ， 那 如 何 实现 反 向 地 刷新 呢 ? 我 们 接 下 来 对 比 一 下 几 种 刷新 方式 吧 。 


2. 刷 新 方式 对 比 


在 缓存 集合 的 创建 过 程 中 ， 我 们 已 经 了 解 到 了 “Propagate” 的 自动 刷新 方式 ， 对 于 AWT 缓 存 集合 来 说 ， 其 为 正 向 刷新 。 而 反 向 刷新 方面 ， 其 支持 两 种 手工 刷新 方式 : “Load” 和 “Refresh” 。 


先 来 看 一 下 “Load” 方 式 吧 ， 与 只 读 缓存 集合 不 同 ， 在 AWT 缓 存 集合 中 ，“Load” 不 只 是 用 于 初始 化 数据 加 载 ， 更 能 实现 差 量 (存在 于 Oracle 而 不 存在 于 TimesTen) 地 将 Oracle 数 据 刷新 到 


TimesTen。 上 述 缓存 集合 cg_awt_601 创 建 后 ，Oracle 表 中 有 5 行 记录 ， 而 TimesTen 表 中 只 有 2 行 ， 存 在 3 行 的 差 量 。 通 过 “Load” 方 式 刷 新 一 次 ， 如 下 示例 ， 可 以 看 到 差 量 的 3 行 记录 被 成 功 刷新 到 
TimesTen 中 。 


Command> load cache group cacheuser.cg awt 601 commit every 100 rows; 
3 cache instances affected. 

Command> select * from alex.tt awt 601; 

总 这 


b> 
总 
d> 


区 5 六 
5 rows found. 


如 果 再 次 “Load” 操 作 ， 因 为 没有 差 量 了 ， 则 没有 记录 被 刷新 ， 示 例如 下 : 


Command> load cache group cacheuser.cg awt 601 commit every 100 rows; 
0 cache instances affected. 


而 “Refresh” 方 式 刷 新 ， 跟 只 读 缓存 集合 就 比较 类 似 了 ， 都 是 一 种 全 量 的 刷新 方式 。 接 着 上 述 的 操作 步骤 ， 如 果 进行 一 次 “Refresh” 刷 新 ， 效 果 会 如 何 呢 ? 示例 如 下 ，5 行 记录 被 全 量 刷新 了 。 


Command> refresh cache group cacheuser.cg awt 601 commit every 100 rows; 
5 cache instances affected. 


可 以 看 到 ， 从 性 能 上 来 说 ，“Load” 的 刷新 方式 似乎 会 更 好 一 些 。 然 而 ， 也 是 需要 明确 待 刷 新 数据 差 量 的 大 小 ， 如 果 差 量 太 大 ， 可 能 “Refresh” 的 方式 会 好 一 些 。 另 一 个 问题 出 来 了 ,会 不 会 出 现存 
在 于 TimesTen 而 不 存在 于 Oracle 的 差 量 数据 呢 ? 正常 情况 下 是 不 会 的 ， 因 为 正 向 刷新 是 自动 完成 的 ， 除 非 复制 代理 进程 出 了 问题 ， 这 样 会 被 TimesTen 视 为 数据 不 一 致 ， 进 而 通过 日 志 进行 数据 恢复 。 


6.3.3 ”SWT 缓 存 集合 


SWT 缓 存 集合 (Synchronous Writethrough Cache Group) 是 一 种 与 AWT 缓 存 集合 比较 类 似 的 缓存 集合 ， 对 于 Oracle 和 TimesTen 都 是 可 读 写 的 ， 且 支持 双向 数据 刷新 。 与 AWT 不 一 样 的 是 其 数据 刷 
新 需要 同步 完成 。 它 的 主要 特性 包括 : 


' TimesTen 事 务 提交 发 起 ， 先 触发 到 Oracle 刷 新 数据 ， 其 操作 为 同步 写 入 ，DML 被 抛 给 DOtacle， 等 待 Oracle 完 成 提交 ，Oracle 完 成 提交 后 ， 再 于 TimesTen 完 成 提交 ，Otacle 无 法 提交 的 话 ，TimesTen 也 会 被 


回 滚 ; 
“ 适合 仅 希望 通过 使 用 TimesTen 加 速 SELECT 操作 的 情况 ， 因 为 DML 操 作 被 要 求 同 步 ，TimesTen 的 事务 提交 依赖 于 Oracle 的 提交 ， 会 严重 影响 DML 性 能 ; 


“ SWT 也 是 支持 双向 刷新 的 ， 但 也 尽 可 能 只 在 TimesTen 单 一 数据 库 源 进行 写 入 ， 以 保证 数据 一 致 性 。 


在 SWT 缓 存 集合 应 用 中 ， 同 样 TimesTen 的 表 为 源 表 ，Oracle 的 表 为 其 缓存 表 ， 主 刷新 方向 是 从 TimesTen 端 到 Oracle 端 ， 可 通过 “Propagate” 刷 新 方式 自动 完成 ， 也 能 支 
持 “Load” 和 “Refresh” 方 式 手工 触发 从 Oracle 到 TimesTen 反 向 刷新 。 


然而 ，SWT 与 AWT 在 数据 刷新 方面 是 有 本 质 区 别 的 : 


“ AWT 是 通过 复制 代理 来 完成 数据 到 Oracle 刷 新 的 ， 如 果 代理 进程 中 断 ， 会 在 代理 重启 后 应 用 日 志 来 完成 Oracle 端 的 事务 补偿 ; 


“ SWT 是 通过 会 话 连接 到 Oracle 操 作 的 ， 如 果 会 话 中 断 ， 事 务 会 同时 从 Oracle 和 TimesTen 端 回 滚 。 


下 面 我 们 通过 一 个 实例 来 演示 一 下 SWT 与 AWT 的 不 同 之 处 吧 。 


步骤 1 创建 一 个 新 的 SWT 缓 存 集合 ， 如 下 所 示 : 


SQL> create table alex.tt swt 601 (id number Primary key, 
2 name varchar2(100)); 一 
Command> create synchronous writethrough cache group 
> cacheuser.cg swt 601 
> from alex.tt swt 601 (id number primary key, 
> name varchar2 (100) ) 7 
Command> cachegroup; 
Cache Group CACHEUSER.CG SWT 601: 
Cache Group Type: Synchronous Writethrough 
Autorefresh: No 
Aging: No aging defined 
Root Table: ALEX.TT SWT 601 
Table Type: Propagate 


步骤 2 此 时 在 TimesTen 端 关闭 复制 代理 后 ， 再 插入 3 行 记录 ， 发 现 该 3 行 记录 还 是 被 衍化 到 Oracle 端 了 ， 可 见 其 刷新 过 程 不 依赖 于 复制 代理 ， 如 下 所 示 : 


Command> call ttRepStop; 

Command> insert into alex.tt swt 601 values (1l, 'a'); 
Command> insert into alex.tt swt 601 values (2, 'b'); 
Command> insert into alex.tt swt 601 values (3, 'c'); 
Command> commit; a 

Command> select * from alex.tt swt 601; 

用 授权 

< a > 

式 全 7 雹 -区 

3 rows found. 

SQL> select * from alex.tt swt 601; 

ID NAME - 


步骤 3 ”初始 化 SWT 和 AWT 缓 存 集合 的 数据 ， 插 入 10 万 行 记录 到 对 应 表 tt_swt_601 和 tt_awt_601 中 : 


Command> begin 
> for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 100000 loop 

insert into alex.tt swt 601 values (i, ‘alex'); 

insert into alex.tt awt 601 values (i, 'alex'); 

end loop; 

commit; 

end; 


# 


> 
> 
> 
> 
> 
> 


步骤 4， 先 来 考察 SWT 缓 存 集合 ， 关 闭会 话 的 自动 提交 功能 (默认 情况 下 ，autocommit=1， 为 开启 自动 提交 功能 ， 在 实际 使 用 中 ， 都 尽 可 能 关闭 该 功能 ) ， 做 一 次 tt_swt_601 全 表 的 name 字 段 更 新 操 
作 ， 并 手工 触发 事务 提交 ， 会 话 进入 等 待 状态 (等待 Oracle 端 完成 事务 提交 的 响应 ) ， 示 例如 下 : 


Command> autocommit 07 

Command> update alex.tt_ swt 601 set name='change'; 
100000 rows updated. 

Command> commit; 


等 待 中 ..… 


此 时 ， 在 Oracle 端 可 以 观察 到 一 个 cacheuser 的 连接 会 话 在 执行 相应 的 更 新 操作 ， 但 其 更 新 也 是 基于 主键 列 逐 行 更 新 的 。 如 果 在 其 提交 完成 前 ， 中 断 其 会 话 会 怎么 样 呢 ? 


SQL> select a.sid，b.sql text 
2 from v$session a，vS$sqlarea b 
3 where a.username="'CACHEUSER' 
4 and a.sql id=b.sql id; 
SID SERIAL# SQL TEXT 
189 7993 UPDATE “ALEX"."TT SWT 601" SET "NAME" = :1 WHERE "ID" = :2 
SQL> alter system kill session '189,7993'; 
System altered 


回 ] 


如 下 可 以 看 到 ，TimesTen 端 会 话 会 提示 报错 ， 因 为 Oracle 端 无 法 正常 完成 事务 提交 ，TimesTen 端 也 不 允许 完成 事务 的 提交 ， 需 要 手工 进行 事务 | 


滚 来 保证 数据 一 致 性 。 示 例如 下 : 


Command> commit; 
5212: No longer connected to Oracle error in OCIStmtExecute (dml): ORA-00028: your 


session has been killed rc = -1 
5055: Cannot synchronize Oracle with TimesTen.The TimesTen transaction must be rolled 
back. 


5025: Commit failure in Oracle. Transaction must be rolled back in TimesTen. 

The command failed. 
Command> rollback; 

Warning 5054: Detect loss of Oracle Connection (ORA-00028) during rollback.Oracle 
rollback will be implicit 


步骤 5 同样 的 操作 应 用 于 AWT 缓 存 集合 的 tt_awt_601 表 ， 事 务 提交 直接 完成 ， 无 须 等 待 Oracle 的 操作 响应 ， 示 例如 下 : 


Command> autocommit 0; 

Command> update alex.tt awt 601 set name='change'; 
100000 rows updated. 

Command> commit; 

直接 完成 。 


和 


此 时 ， 如 果 异 常 中 断 所 有 复制 代理 进程 (其 进程 可 以 设置 多 个 并 行 子 进程 ， 只 要 不 是 所 有 进程 都 中 断 ， 数 据 刷 新 都 能 正常 完成 ) ， 会 出 现 短暂 的 数据 不 一 致 ， 当 复制 代理 重新 正常 工作 后 ， 会 进行 一 次 
站 偿 刷新 ， 来 保证 数据 一 致 。 


在 实际 应 用 中 ， 之 所 以 使 用 TimesTen 来 作为 Oracle 的 缓存 ， 就 是 要 提高 数据 库 的 响应 速度 。 如 果 使 用 SWT 的 方式 来 保证 数据 的 强 一 致 性 ， 其 性 能 还 不 如 在 应 用 端 分 别 向 TimesTen 和 Oracle 发 起 相同 的 


有 有 务 。 SWT 虽 然 能 提高 查询 性 能 ， 但 将 使 DML 性 能 变 得 更 差 ， 这 是 得 不 偿 失 的 ， 非 必要 情况 下 ， 尽 可 能 不 要 使 用 SWT。 


6.3.4 _ 自 定义 缓存 集合 


严格 意义 上 来 说 ， 只 读 缓存 集合 、AWT 缓 存 集合 、SWT 缓 存 集合 都 只 能 算是 单 向 的 数据 刷新 ， 要 实现 双向 刷新 是 需要 人 工 干预 的 ， 是 否 可 以 实现 真正 意义 上 的 双向 自动 化 数据 刷新 呢 ?” 当 然 可 


以 ，TimesTen 提 供 了 一 种 比较 灵活 的 缓存 集合 方式 : 自 定义 缓存 集合 (Usermanaged Cache Group) 。 


“ 数据 的 强 一 致 性 ; 


“ 刷新 过 程 自动 化 ， 无 须 人 工 干预 。 


对 于 自 定义 缓存 集合 来 说 ，Oracle 和 TimesTen 构 成 了 两 个 分 布 式 的 数据 库 ， 作 为 一 个 成 熟 的 数据 库 产品 ，TimesTen 是 需要 保证 数据 强 一 致 性 的 。 根 据 分 布 式 数据 库 的 三 元 悖 论 ， 那 必然 要 牺牲 掉 数 据 


库 的 可 用 性 ， 也 就 是 说 Oracle 端 和 TimesTen 端 的 任何 数据 变更 和 对 应 刷新 都 需要 在 同步 事务 中 完成 。 


当 TimesTen 作 为 Oracle 前 置 缓存 而 存在 的 时 候 ， 我 们 可 以 认为 数据 存在 Oracle 数 据 库 中 将 是 更 可 靠 的 ， 要 尽 可 能 保证 在 Oracle 端 可 直接 获取 到 全 量 的 数据 。 在 只 读 缓存 集合 和 SWT 缓 存 集合 中 ， 这 一 


点 是 能 够 做 到 的 ， 同 时 其 数据 刷新 过 程 也 都 是 在 同步 事务 中 完成 ; 而 对 于 AWT 缓 存 集合 ， 其 本 质 上 就 是 一 个 异步 事务 的 过 程 ， 如 果 出 现 数据 不 一 致 ， 需 要 通过 人 工 干预 ， 则 可 应 用 TimesTen 日 志 来 进行 数 
据 补 偿 。 


如 此 看 来 ， 实 现 了 双向 自动 化 刷新 的 自 定义 缓存 集合 ， 其 本 质 就 是 实现 了 “只 读 缓存 集合 + SWT 缓 存 集合 ” ， 下 面 我 们 通过 一 个 实例 来 看 一 下 吧 。 具 体 步骤 如 下 : 


步骤 1 创建 一 个 Oracle 测 试 表 tt_udef 601， 及 其 对 应 自 定 义 缓存 集合 cg_udef 601。 需 要 注意 的 是 ， 如 果 缓 存 集合 要 实现 Autorefresh 功 能 ， 就 必须 在 创建 时 就 开启 ， 默 认 情况 是 不 开启 Autorefresh 


功能 的 。 在 自 定义 的 缓存 集合 中 ， 如 果 要 实现 自动 衍化 刷新 ， 需 要 在 定义 缓存 集合 表 的 时 候 ， 显 式 地 指定 “propagate” 属 性 (在 非 自 定义 缓存 集合 中 是 不 允许 指定 readonly/not propagate/propagate 


属性 的 ) 。 示 例如 下 : 


SQL> create table alex.tt udef 601 (id number primary key, 
2 name varchar2(100)); 

Command> create usermanaged cache group cacheuser.cg udef 601 
> autorefresh mode incremental interval 5 seconds 
> from alex.tt udef 601 (id number primary key, 
> name varchar2 (100), 
> propagate); 

Command> cachegroup; 

Cache Group CACHEUSER.CG UDEF 601: 

Cache Group Type: User Managed 
Autorefresh: Yes 

Autorefresh Mode: Incremental 
Autorefresh State: Paused 
Autorefresh Interval: 5 Seconds 
Autorefresh Status: ok 

Aging: No aging defined 

Root Table: ALEX.TT UDEF 601 
Table Type: Propagate 


需要 注意 的 是 ， 因 为 缓存 集合 开启 了 Autorefresh 功 能 支持 ， 所 以 不 能 关闭 缓存 代理 ， 否 则 Autorefresh 无 法 使 用 。 但 是 复制 代理 可 以 关闭 ， 因 为 其 propagate 刷 新 的 机 制 和 SWT 是 一 样 的 ， 都 是 通过 会 


话 连 接 来 实现 的 。 


Command> call ttCacheStop; 

Command> call ttRepStop; 

Command> alter cache group cacheuser.cg udef 601 set autorefresh 
> state on; 

Warning 5002: Unable to connect to the cache agent for 

/DataStore/ttalex/ttalex; check agent status 

Warning 5051: Commit message to cache agent failed. Cache agent must 

be restarted 

Command> call ttCacheStart; 

Command> alter cache group cacheuser.cg udef 601 set autorefresh 
> state on; 


步骤 2 在 Oracle 表 插入 3 行 记录 ， 然 后 在 TimesTen 表 插入 另外 3 行 记录 ， 等 待 5 秒 后 数据 被 双向 自动 刷新 到 了 TimesTen 表 和 Oracle 表 中 。 示 例如 下 : 


SQL> insert into alex.tt udef 601 values (1,'Oracle'); 


SQL> insert into alex.tt udef 601 values (3,'Oracle'); 

SQL> insert into alex.tt udef 601 values (5,'Oracle'); 

SQL> commit; a 

Command> insert into alex.tt udef 601 values (2,'TimesTen'); 
Command> insert into alex.tt udef 601 values (4,'TimesTen'); 
Command> insert into alex.tt udef 601 values (6,'TimesTen'); 
Command> commit; 


< 2, TimesTen > 

< 3, Oracle > 

< 4, TimesTen > 

< 5, Oracle > 

< 6, TimesTen > 

SQL> select * from alex.tt udef 601; 


4 TimesTen 
6 TimesTen 
1 Oracle 
3 Oracle 
5 Oracle 
2 TimesTen 


从 以 上 的 实例 来 看 ， 自 定义 缓存 集合 看 似 功 能 强大 ， 但 并 不 是 很 有 使 用 价值 。 图 6-6 所 示 为 进行 插入 操作 测试 的 结果 ， 从 插入 1 行 记录 递增 到 插入 10000 行 记录 ， 期 间 自 定义 缓存 集合 都 比 SWT 缓 存 集合 
的 性 能 差 很 多 。 


100 000 
80 000 
60 000 
40 000 
20 000 

0 


国 SVV 工 7.904 8.704 13.225 54.292 273.616 


48.34 395.136 2287.025 83 051.669 


执行 时 间 (ms) 


图 6-6 SWT 与 自 定义 缓存 集合 插入 性 能 对 比 


那 自 定义 缓存 集合 的 时 间 都 消耗 在 哪里 了 呢 ? 通过 下 面 的 插入 操作 日 志 可 以 看 到 ， 在 进行 TimesTen 内 存 插入 操作 的 时 候 ， 自 定义 缓存 集合 是 不 存在 劣势 的 ， 问 题 出 在 commit 提 交 阶 段 。 在 提交 阶段 ， 
为 了 保证 数据 的 一 致 性 ，TimesTen 需 要 先 连 接 到 Oracle 完 成 刷新 的 事务 提交 ， 再 于 TimesTen 进 行事 务 提交 。 


Command> autocommit 0; 

Command> set timing on 

Command> begin 
> for i in 20001 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 30000 loop 
> insert into alex.tt swt 601 values (i, 'alex'); 
> end loop;end loop; 


> end; 

3 了 
Execution time (SQLExecute) = 0.351574 seconds . 
Command> commit; 
Execution time (SQLTransact) = 0.143826 seconds. 


Command> begin 
> for i in 20001 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 30000 loop 
> insert into alex.tt udef 601 values (i, 'alex'); 
> end loop; 
> end; 
> 
Execution time (SQLExecute) = 0.349958 seconds. 
Command> commit; 
Execution time (SQLTransact) = 79.903589 seconds. 


当 自 定义 缓存 集合 发 起 提交 的 时 候 ， 在 Oracle 端 可 以 捕捉 到 以 下 会 话 行为 ，TimesTen 连 接 到 Oracle 进 行 数据 刷新 的 会 话 还 对 TimesTen 数 据 字典 表 TT_ 06_79820 | 进行 了 大 量 的 更 新 操作 。 该 表 其 实 是 
Oracle 到 TimesTen 增 量 自动 刷新 的 日 志 记录 表 ， 为 了 保证 数据 一 致 性 ， 对 该 表 的 更 新 是 不 可 避免 的 ， 这 样 效 率 自然 就 变 得 很 低 了 。 但 如 果 自 定义 缓存 集合 采用 的 全 量 自动 刷新 模式 ， 就 不 存在 
TT_06 79820 | 的 更 新 操作 ， 效 率 就 能 跟 SWT 一 样 高 。 


SQL> select a.module, b.sql text 


from v$session a, v$sqlarea b 
3 where a.username = 'CACHEUSER' 
4 and a.sql id = b.sql _ id” 
MODULE 加 SQL TEXT 
ttIsqlCcmd@testserver (TNS V1-V3) UPDATE CACHEUSER.TT 06 79820 1 SET 
ft cacheGroup = :"SYS B 0"*~:"SYS B 1"+ 
:"SYS B 2" WHERE ft _ cacheGroup = 
:"SYS B 3" AND logseq = :"SYS B 4" 
AND xid = dbms transaction. 
local transaction id AND "ID" = :1 


综合 来 阅 ， 自 定义 缓存 集合 相 比 SWT 缓 存 集合 更 加 不 具有 实用 价值 。 我 们 在 选择 缓存 集合 的 时 候 ， 如 果 出 于 性 能 保证 的 考虑 ， 可 以 选择 只 读 缓存 集合 和 AWT 缓 存 集合 ， 而 如 果 对 数据 一 致 性 要 求 很 高 的 
话 ， 可 以 选择 只 读 缓存 集合 和 SWT 缓 存 集合 。 


6.3.5 “多 表 缓 存 集合 


前 面 说 到 ， 一 个 缓存 集合 是 可 以 包含 多 个 表 的 ， 且 这 些 表 都 必须 是 相互 关联 的 。 反 之 ， 一 个 表 却 是 不 可 以 同时 被 包含 在 不 同 的 两 个 缓存 集合 中 的 。 


通过 一 个 实例 来 了 解 一 下 多 表 的 缓存 集合 吧 。 如 下 所 示 ， 在 一 个 缓存 集合 中 ， 需 要 使 用 外 键 关 联 来 为 多 表 建 立 联系 。 


Command> create asynchronous Writethrough cache group 
> cacheuser.cg awt 602 

from 

alex.tt awt 602 root 


id number not null, 
name varchar2(100), 


> 
> 
> (人 
> 
> 
> Primary key (id) 


一 风 一 
~ 


ex.tt awt 602 child 


cid number not null, 
name varchar2(100), 
id number not null, 
primary key (cid), 


VvVvvVvvvvvvyv 


foreign key (id) references alex.tt awt 602 root (id) 


然而 ， 在 设计 过 程 中 ， 我 们 需要 注意 的 是 ， 这 种 外 键 关 联 关系 不 应 该 是 TimesTen 所 要 求 的， 而 应 该 是 Oracle 所 要 求 的 。 在 进行 TimesTen 缓 存 的 时 候 ， 为 了 保证 数据 的 强 一 致 性 ， 需 要 与 Oracle 的 外 键 
关系 保持 一 致 。 换 而 言 之 ， 如 果 Oracle 端 没有 外 键 关 系 ， 就 不 要 画蛇添足 地 在 TimesTen 缓 存 过 程 中 追加 外 键 关系 。 比 较 好 的 做 法 是 ， 尽 可 能 保证 一 个 缓存 集合 中 只 包含 一 个 表 ， 这 对 性 能 提升 是 非常 有 帮助 


的 。 


另 一 方面 ， 值 得 特别 关注 的 是 ， 当 TimesTen 作 为 Oracle 的 缓存 进行 使 


6.3.6 ”缓存 老化 


所 谓 缓存 者 化 (Aging) 并 不 是 真正 意义 的 老化 ， 而 是 定时 将 缓存 集合 的 表 中 


1) 基于 LRU 老 化 : 定时 将 缓存 集合 的 表 中 最 近 最 少 使 用 的 数 拉 


的 时 候 ， 其 缓存 集合 中 表 的 字段 类 型 尽 可 能 与 Oracle 保 持 一 致 。 


足 条 件 的 数据 行 从 缓存 表 中 清理 出 去 ， 其 机 制 分 为 基于 LRU 和 基于 时 间 两 种 : 


居 行 从 缓存 表 中 清理 掉 。 可 以 通过 内 置 存储 过 程 ttAgingLRUConfig 来 进行 配置 ， 如 下 所 示 : 


Command> Call ttAgingLRUConfig(); 
< .8000000, .9000000, 1 > 
Command> desc ttAgingLRUConfig; 
Procedure TTAGINGLRUCONFTIG: 
Parameters: 
LOWUSAGETHRESHOLD 
HIGHUSAGETHRESHOLD 
AGINGCYCLE 


BINARY FLOAT 
BINARY FLOAT 
TT_INTEGER 


该 存储 过 程 有 三 个 参数 : 


" LowUsageThreshold: 最 小 固定 内 存 空间 使 用 率 赋值， 默认 值 80%; 
“ HighUsageThreshold: 最 大 国定 内 存 空间 使 用 率 阔 值 ， 默 认 值 90%; 


. AgingCycle; 自动 清理 操作 频率 (单位 : 分 钟 ) 。 


2) 基于 时 间 老化 : 基于 缓存 集合 的 父 表 的 某 一 个 时 间 字 段 来 清理 数据 ， 定 期 将 若 
据 生命 丑 


期 管理 ， 将 过 期 的 历史 数据 清理 掉 ， 节 省 出 大 量 的 内 存 空间 。 


F{SECONDIMINUTEIHOURIDAY} 之 前 的 数据 清理 掉 。 这 种 做 法 也 是 比较 常 


的 方法 ， 可 以 


于 TimesTen 数 据 库 的 数 


需要 注意 的 是 ， 不 论 是 基于 LRU 的 老化 ， 还 是 基于 时 间 的 老化 ， 都 是 针对 于 TimesTen 缓 存 表 的 ，Oracle 端 的 数 H 


开 。 


步骤 1 
新 建 只 读 缓存 集合 ， 加 载 数据 。 示 例如 下 : 


居 不 受 其 


体 步骤 如 下 哲 


影响 。 下 面 我 们 通过 一 个 实例 来 展示 一 下 基于 时 间 的 老化 设置 ， 


需要 重新 创建 一 个 只 读 缓存 集合 ， 包 含 日 期 时 间 字 段 ， 对 现 有 的 缓存 集合 追加 非 空 的 日 期 时 间 字段 是 不 现实 的 。 在 Oracle 数 据 库 新 建 一 个 表 tt_readonly_602， 并 初始 化 数据 ， 再 于 TimesTen 应 


SQL> create table alex.tt readonly 602 (id number primary key, 


2 ts date not null); 
SQL> insert into alex.tt readonly 602 values 
SQL> insert into alex.tt readonly 602 values 
SQL> insert into alex.tt readonly 602 values 
SQL> insert into alex.tt readonly 602 values 
SQL> commit; 有 网 


1, sysdate-10); 
2, sysdate-5); 
3, sysdate); 

4, sysdate+5); 


Command> create readonly cache group cacheuser.cg readonly 602 


> from alex.tt readonly 602 (id number primary key, 
> ts date not null); 

Command> load cache group cacheuser .cg readonly 602 commit 
> every 100 rows; 可 本 


此 时 ， 不论 是 Oracle 端 ， 还 是 TimesTen 端 ， 表 均 包 含 4 行 记录 。 


步骤 2 在 TimesTen 端 给 缓存 表 tt_readonly_602 基 于 ts 列 追 加 老化 设置 ,设置 5 天 前 (不 包含 5 天 ) 的 数据 为 老化 数 
。 SQL 语 句 如 下 所 示 : 


Command> call ttCacheStop; 

Command> alter table alex.tt readonly 602 add aging use ts 
> lifetime 5 days cycle 1 days; 

Command> call ttCacheStart; 

Command> cachegroup cg _ readonly 602; 
Cache Group CACHEUSER.CG READONLY 602: 
Cache Group Type: Read Only 

Autorefresh: Yes 

Autorefresh Mode: Incremental 
Autorefresh State: On 
Autorefresh Interval: 5 Minutes 
Autorefresh Status: ok 


Aging: Timestamp based uses column TS lifetime 5 days cycle 1 day on 


Root Table: ALEX.TT READONLY 602 
Table Type: Read Only 


居 ， 每 一 天 一 次 的 频率 进行 清理 。 该 设置 过 程 必须 先 关闭 缓存 代理 ， 设 置 完成 后 再 : 


此 时 ，TimesTen 的 缓存 表 中 ，ID=1 的 记录 因为 数据 老化 被 自动 清理 掉 了 。 验 证 如 下 : 


中 出 现 。 即 使 使 


Command> select * from alex.tt readonly 6027 
< 2, 2014-04-22 14:08:00 > 

< 3, 2014-04-27 14:08:00 > 

< 4, 2014-05-02 14:08:01 > 

3 rows found. 


老化 策略 设置 完成 后 ， 如 果 在 Oracle 端 再 插入 新 的 数据 行 ， 缓 存 代 理 在 
手工 “Refresh” 全 量 刷新 ， 老 化 数据 也 不 会 被 TimesTen 缓 存 ， 除 非 将 老化 策略 的 设置 关闭 。 关 闭 的 SQL 语句 如 下 所 示 : 


动 刷新 数据 到 TimesTen 缓 存 表 时 ， 会 判断 该 数据 行 是 否 满足 老化 策略 的 条 件 ， 如 果 满 足 ， 则 该 行 数据 不 会 在 TimesTen 缓 存 表 


Command> call ttCacheStop; 
Command> alter table alex.tt readonly 602 set aging off; 
Command> call ttCacheStart; 


值得 注意 的 是 ， 在 关闭 了 数据 老化 策略 之 后 ， 需 要 追加 做 一 次 缓存 集合 全 量 的 数据 刷新 操作 ， 以 防 造成 数据 的 不 一 致 。 


总 体 来 说， 缓存 老化 可 以 带 来 以 下 益处 : 
“ 节省 内 存 空间 ， 即 时 清理 过 期 数据 ; 


“ 可 以 用 作 数 据 生 命 周期 管理 ， 推 荐 采用 基于 时 间 的 缓存 老化 。 


6.3.7 ”缓存 过 滤器 


有 了 缓存 老化 的 策略 ， 是 否 可 以 将 其 作为 一 个 数据 过 滤器 来 用 呢 ? 我 们 说 最 好 不 要 ， 缓 存 老化 最 佳 的 应 用 场景 还 是 用 作 过 期 历史 数据 的 清理 。 而 数据 的 过 滤 ， 我 们 可 以 在 缓存 集合 创建 的 时 候 ， 指 
“WHERE” 子 句 的 谓词 来 进行 设置 。 当 然 ， 该 方法 也 可 用 作 缓 存 集合 分 库 分 表 策 略 的 实现 。 


半 


如 下 的 示例 中 ， 新 建 了 一 个 与 cg_readonly_601 类 似 的 缓存 集合 cg_readonly 603， 在 创建 过 程 中 ， 指 定 了 where mod (id，2) = 1 子 句 作 为 数据 过 滤 ， 当 加 载 和 刷新 数据 到 TimesTen 缓 存 集合 的 时 
候 ， 只 有 符合 过 滤 条件 ，id 为 奇数 的 行 才 被 缓存 。 


SQL> create table alex.tt readonly 603 (id number primary key, 
2 name Varchar2 (100) ) 7 
SQL> insert into alex.tt readonly 603 values (1, 'a'); 
SQL> insert into alex.tt readonly 603 values (2, 'b'); 
SQL> insert into alex.tt readonly 603 values (3, 'c'); 
SQL> commit; 
Command> create readonly cache group cacheuser.cg readonly 603 
> from alex.tt readonly 603 (id number primary key, 
> name Varchar2 (100)) 
> where mod(id,2)=1; 
Command> load cache group cacheuser.cg readonly 603 commit 
> every 100 rows; 加 所 
2 cache instances affected. 
Command> select * from alex.tt readonly 603; 
7 沽 条 a mi 
a 记 : 区 
2 rows found. 


需要 注意 的 是 ， 缓 存 过 滤器 的 使 用 是 有 不 少 制约 条 件 的 ， 包 括 : 


“ 缓存 过 滤器 对 于 AWT 缓 存 集合 和 SWT 缓 存 集合 是 无 效 的 ; 


“ 缓存 过 滤器 对 于 动态 过 滤 条 件 ( 如 where ts>=sysdate-60) ， 是 无 法 动态 过 滤 现 有 数据 的 。 


6.3.8 ”动态 缓存 集合 


动态 缓存 集合 (Dynamic Cache Group) ， 顾 名 思 义 就 是 对 TimesTen 的 缓存 集合 进行 动态 数据 加 载 ， 如 果 在 Timesten 中 查询 不 到 满足 条 件 的 数据 后 ， 将 自动 到 Oracle 中 去 查找 ， 如 果 在 Oracle 中 找 
到 ， 就 将 该 数据 加 载 到 Timesten 中 。 


然而 ， 从 Oracle 到 TimesTen 动 态 加 载 也 是 有 限制 条 件 的 : 
“ 只 有 按照 主键 进行 等 值 查询 的 数据 才 被 加 载 到 TimesTen 中 ; 
“ 按照 主键 进行 范围 查询 (大 于 、 小 于 、between 等 ) 的 时 候 ， 不 会 动态 加 载 数据 ; 


“ 按照 非 主 键 进行 查询 时 ， 是 不 会 动态 加 载 数据 的 。 


动态 缓存 集合 并 不 是 一 种 单独 的 缓存 集合 类 型 ， 而 是 四 种 主要 缓存 集合 的 功能 扩展 ， 其 目的 也 是 为 了 节省 内 存 空间 的 开销 ， 仅 加载 当前 需要 的 数据 。 基 于 这 个 目的 ， 我 们 在 创建 动态 缓存 集合 后 ， 最 好 
不 要 进行 数据 的 初始 化 加 载 ， 而 是 保留 一 个 空 的 缓存 集合 即 可 。 


下 面 通过 一 个 实例 来 看 一 下 动态 缓存 集合 是 如 何 工作 的 吧 。 具 体 步骤 展开 如 下 : 


步骤 1 将 SWT 缓 存 集合 cg_swt_601 重 建成 一 个 动态 缓存 集合 ， 创 建 语 句 非常 简单 ， 在 创建 普通 缓存 集合 的 基础 上 加 上 一 个 “dynamic” 关 键 字 即 可 ， 如 下 所 示 : 


Command> create dynamic synchronous writethrough cache group 
> cacheuser.cg_ swt _ 601 
> from alex.tt swt 601 (id number primary key, 
> name varchar3 (100)); 


此 时 ， 发 现 动态 缓存 集合 默认 是 开启 了 基于 LRU 的 缓存 老化 设置 ， 这 也 是 出 于 尽 可 能 节省 内 存 来 考虑 的 。 比 较 好 的 做 法 是 直接 关闭 掉 ， 以 防 数据 反复 进出 的 额外 开销 。 


Command> cachegroup; 
Cache Group CACHEUSER.CG SWT_601: 
Cache Group Type: Synchronous Writethrough (Dynamic) 
Autorefresh: No 
Aging: LRU on 
Root Table: ALEX.TT SWT 601 
Table Type: Propagate 
Command> alter table alex.tt_swt_601 set aging off; 


步骤 2 ”如 果 进 行 主键 非 等 值 查询 、 非 主键 查询 、 全 表 查 询 ， 数 据 都 未 能 被 动态 加 载 ， 具 体 如 下 : 


Command> select * from alex.tt_Swt 601 where id>10; 

0 rows found. 

Command> select * from alex.tt_Swt_601 where id<10; 

0 rows found. 

Command> select * from alex.tt swt 601 where id between 1 and 10; 
0 rows found. 

Command> select * from alex.tt swt 601 where name='change'; 

0 rows found. 0 

Command> select * from alex.tt swt 601; 

0 rows found. 三 


步骤 3 ” 当 进 行 了 id=10 的 等 值 查询 后 ，TimesTen 表 tt_swt_601 就 成 功 加 载 了 1 行 记录 ， 之 后 所 有 类 型 的 查询 都 能 查 到 该 行 记录 。 


Command> select * from alex.tt swt 601 where id=10; 

< 10, change > ee 

1 row found. 

Command> select * from alex.tt swt 601 where id between 1 and 10; 
< 10, change > 

1 row found. 


Command> select * from alex.t 
< 10，change > 
1 row found. 


t swt 601; 


出 于 合理 化 设计 的 考虑 ,我 们 需 


6.3.9 PassThrough 属 性 


尽 可 能 避免 使 用 动态 缓存 集合 ， 其 不 可 控 因素 比较 多 ， 不 利于 运 维 的 稳定 。 


PassThrough 是 TimesTen 缓 存 集合 的 另 一 个 比较 重要 的 属性 ， 通 过 对 PassThrough 的 设置 ， 可 以 控制 是 否 将 TimesTen 端 发 起 的 SQL 语句 抛 到 Oracle 数 据 库 中 执行 。 


该 属性 一 共 分 为 6 个 等 级 ， 具 体 说 明 如 表 6-4 所 示 : 


PassThrough 属性 
0 (默认 ) 


iD 


通常 情况 下 ， 全 局 动态 的 AWT 缓 存 集合 是 不 大 有 机 会 被 


6.4 ”高 可 用 复制 架构 


所 有 SQL 


表 6-4 PassThrough 属 性 说 明 


语句 均 在 TimesTen 执行 


说 有明 


所 有 SQL 语句 均 在 TimesTen 执行 ， 如 果 相 关 表 在 TimesTen 不 存在 或 者 出 现 TimesTen 语 
法 错误 ， 则 DML 语句 和 SELECT 语句 被 抛 给 Oracle 执行 , 但 DDL 语句 不 会 被 抛 给 Oracle 


对 于 只 读 缓存 集合 和 自 定 义 缓 存 


PassThrough=1 的 设置 执行 
语句 均 被 抛 给 Oracle 执行 ,但 对 于 全 局 动态 AWT 缓存 集合 ，DML 语句 是 不 被 


所 有 SQL 
允许 的 


= AN 
< 口 ， 


DML 操作 被 抛 给 Oracle 执行 ， 其 他 情况 参照 


所 有 SQL 语句 均 在 TimesTen 执行 ， 但 对 于 全 局 动态 AWT 缓存 集合 ， 如 果 出 现 不 满足 动态 


加 载 查询 标准 的 SELECT 语句 ， 贝 
语句 均 在 TimesTen 执行 ， 但 对 于 全 局 动态 AWT 缓存 


所 有 SQL 


给 Oracle 执行 


在 容 灾 要 求 非常 高 的 今天 ， 高 可 
构 设 计 方 法 ， 可 以 说 其 兼顾 了 Oracle 


的 稳定 和 MySQL 的 灵活 | 


在 6.1.3 节 中 ， 已 经 介绍 到 了 使 


下 面 我 们 将 具体 展开 介绍 复制 这 种 高 可 用 的 架构 。 


6.4.1 复制 原理 


在 6.3.2 节 中 ， 我 们 介绍 到 复制 代理 可 以 上 


在 具体 展开 之 前 ， 我 们 先 来 了 解 


一 下 复制 技术 的 原理 及 3 


到 的 (除非 使 用 了 缓存 网 格 的 高 可 用 架构 ) ， 


被 抛 给 Oracle 执行 


ee 合 ， 如 果 出 现 不 满足 动态 
加 载 查询 标准 的 SELECT 语句 ， 则 在 TimesTen 的 事务 更 新 全 部 刷新 到 Oracle 之 后 ， 再 被 抛 


PassThrough 取 值 0 或 者 3 即 可 ， 以 防止 造成 操作 混乱 。 


的 特点 。 但 是 在 实际 使 用 当中 ， 我 们 不 得 不 在 稳定 和 灵活 之 间 寻 求 一 种 平衡 。 


要 特征 : 


* 复制 是 基于 事务 (Transaction) 日 志 进 行 的 ， 也 就 是 说 触发 复制 的 条 件 是 事务 的 提交 ; 


“ 复制 代理 是 通过 TCP/IP 流 套 接 (Stream Socket) 收发 更 新 信息 的 ; 


“ 在 事务 日 志 传输 和 应 用 过 程 中 ， 是 基于 时 间 戳 进行 的 ， 能 有 效 避 免 更 新 版 本 冲突 等 问题 ; 


根据 复制 机 制 不 同 ， 复 制 又 可 分 
“ 异步 复制 (Asynchronous Repli 


“ 回执 复制 (Return Receipt Repl 


为 以 下 三 种 类 型 ; 
cation) 


ication ) 


“ 双 保 险 复 制 (Return Twosafe Replica-tion) 


接 下 来 我 们 就 来 具体 了 解 一 下 这 三 种 复制 类 型 的 实现 原理 和 各 自 的 特点 吧 。 


1. 异 步 复 制 


所 谓 异 步 复制 ， 就 是 复制 操作 的 发 送 方 不 必 等 待 接收 方 的 反馈 ， 而 直接 完成 事务 提交 ， 并 反馈 给 应 


台 复 制 过 程 而 拖累 其 整体 性 能 。 


异步 复制 过 程 的 流程 如 下 说 明 : 


复制 代理 复制 (包括 : 主 从 复制 、 双 主 复制 、 环 形 复制 、 衍 生 复 制 ) 可 以 实现 多 样 化 的 容 灾 方式 ， 这 也 是 TimesTen 首 推 的 一 种 高 可 


于 AWT 缓 存 集合 的 TimesTen 到 Oracle 的 数据 刷新 。 然 而 ， 复 制 代理 最 主要 的 作用 还 是 用 于 在 不 同 Timesten 数 据 库 之 间 复 制 数据 。 


。 如 苞 


6-7 所 示 ， 异 步 复制 模式 速度 快 、 效 率 高 


， 可 以 充分 保证 发 送 方 对 应 


架构 似乎 成 了 一 套数 据 库 的 标准 架构 。 不 论 是 灾难 的 恢复 ， 还 是 错误 的 回 退 ， 高 可 用 架构 的 作用 都 是 不 言 而 喻 的 。 在 TimesTen 内 存 数据 库 中 ， 也 是 有 多 种 的 高 可 上 


架构 实现 方式 。 


快速 响应 ， 不 会 


溢 


因为 后 


步 又 发 送 方 接收 方 
OD 应 用 COMMIT 提交 
© 立刻 返回 应 用 COMMIT 提交 成 功 
® 通过 日 志 绥 存 写 和 日 志文 件 
@ 将 更 新 信息 发 送 给 复制 代理 
© 将 更 新 信息 发 送 到 接收 方 的 复制 代理 
(O) 确认 更 新 信息 接收 成 功 
CO 应 用 更 新 信息 ， 并 写 人 Data Store 区 域 
® 记录 接收 方 的 日 志文 件 

2. 回 执 复制 


回执 复制 实质 上 是 一 种 半 同 步 复制 ， 为 什么 说 是 半 同 步 呢 ? 如 图 6-8 所 示 ， 当 复制 请 求 发 送 到 接收 方 的 复制 代理 ， 并 返回 成 功 接收 信息 ， 发 送 方 即 视 为 复制 完成 ， 反 馈 事务 完成 信息 给 应 用 。 然 而 ， 此 时 
复制 过 程 仍 在 接收 方 进行 ， 并 没有 真正 完成 ， 发 送 和 接收 双方 还 是 会 存在 短暂 的 数据 不 一 致 情况 。 回 执 复制 模式 虽然 可 以 检测 无 法 同步 的 情况 ， 但 是 无 法 加 以 有 效 控制 。 


发 送 万 人 ® 


~ i 


— 


日 志文 人 


is 


严 


一 


日 志文 件 


p>. 


接收 广 
日 志 缓 存 


图 6-7 ”异步 复制 模式 原理 


WV Data Store > 
接收 方 


日 志 缓 存 


图 6-8 回执 复制 模式 原理 


回执 复制 过 程 的 流程 如 下 说 明 : 


步 又 发 送 方 接收 方 
中 应 用 COMMIT 提交 
© 通过 日 志 绥 存 写 人 日 志文 件 
® 将 更 新 信息 发 送 给 复制 代理 
由 将 更 新 信息 发 送 给 复制 代理 
3) 确认 更 新 信息 接收 成 功 
(©) 立刻 返回 应 用 COMMIT 提交 成 功 
©@ 应 用 更 新 信息 ， 并 写 入 Data Store 区 域 
(8) 记录 接收 方 的 日 志文 件 
3. 双 保险 复制 


双 保险 复制 是 真正 意义 上 同步 复制 ， 顾 名 思 义 就 是 复制 过 程 对 发 送 和 接收 双方 都 是 “保险 ”的 ， 即 在 任何 时 点 ， 双 方 都 能 保证 数据 的 完全 一 致 。 如 图 6-9 所 示 ， 应 用 发 起 的 事务 是 先 传送 到 接收 方 ， 
接收 方 完成 提交 后 ， 再 于 发 送 方 完成 提交 ， 最 后 反馈 给 应 用 。 该 模式 下 ， 原 本 在 一 个 数据 库 上 提交 的 事务 ， 会 被 串 行 在 两 个 数据 库 上 提交 ， 还 有 额外 的 网 络 传送 延 时 ， 这 对 要 求 高 性 能 的 TimesTen 应 用 
是 “有 害 的 ”。 


等 待 
将 


发 送 方 ”|) 六 用 OD 


(O) Data Store 


/6 
日 志 组 爱 存 DO/ 一 一 


代理 日 志文 件 


(3) a 


代理 日 志文 件 
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Data Store 


日 志 缓 存 


图 6-9 ” 双 保 险 复制 模式 原理 图 


接收 方 


双 保 险 复制 过 程 的 流程 如 下 说 明 : 


步骤 发 送 方 接 收 方 

中 应 用 发 起 COMMIT 提交 

© 将 更 新 信息 A 

® 将 更 新 信息 发 送 给 复制 代理 

由 接收 方 COMMIT 提交 ， 并 写 入 Data Store 
G@) 记录 接收 方 的 日 志文 件 

0) 确认 更 新 信息 接收 成 功 

© 送 方 COMMIT 提交 

® 通过 日 志 缓存 写 入 日 志文 件 

GO) 返回 应 用 完成 信息 


比较 上 述 三 种 复制 模式 ， 如 何 进行 架构 的 选择 呢 ?” 从 数据 同步 实时 性 和 性 能 的 维度 来 看 : 
“ 同步 实时 性 : 异步 复制 二 回执 复制 二 双 保 险 复制 ; 


: 性 能 : 异步 复制 回执 复制 双 保险 复制 。 


从 一 些 实际 经 验 来 看 ， 异 步 复 制 还 是 颇 受 青睐 的 ， 因 为 使 用 TimesTen 的 初 训 就 是 为 了 获取 性 能 优势 ， 这 和 Oracle 的 使 用 是 有 差别 的 。 尽 管 异 步 复制 存在 以 下 缺点 : 


“ 在 某 些 情况 下 ， 可 能 产生 事务 日 志 扒 积 ， 造 成 主 备 数据 短暂 不 完全 一 致 的 现象 ， 包 括 : 
“ 主机 产生 大 事务 和 长 事务 ， 导 致 日 志 堆 积 ; 
“ 某 些 查询 操作 不 及 时 提交 ， 也 可 能 产生 长 事物 ， 导 致 日 志 堆积 。 


“ 当 出 现 日 志 堆 积 时 ， 主 机 发 生 了 故障 ， 为 了 保证 数据 不 丢失 ， 无 法 直接 切换 到 备 机 ， 直 接 恢 复 主 机 的 时 间 可 能 会 比较 长 。 


但 是 与 异步 复制 相 比 ， 回 执 复制 和 双 保 险 复制 虽然 理论 上 可 以 保证 主机 和 备 机 数据 即时 一 致 ， 但 以 下 问题 同样 无 法 避免 


“ 性 能 低下 ， 会 影响 应 用 的 性 能 ， 导 致 性 能 优化 的 初衷 无 法 达成 ; 


“ 如 果 发 生 大 事务 和 长 事务 ， 同 样 会 导致 复制 起 时， 无 法 避免 产生 日 志 堆 积 ， 同 步 复 制 的 优势 丙 失 。 


综 上 所 述 ， 异 步 复制 模式 为 值得 推荐 的 ， 其 可 以 通过 ReplicationParallelism 人 参数 的 配置 来 实现 并 发 复制 。 但 如 果 生 


6.4.2 ASP 架构 


了 解 了 复制 的 原理 和 特性 ， 那 我 们 如 何在 TimesTen 种 类 繁多 的 复制 架构 中 选择 最 合适 了 
计 思 路 ， 采 用 简单 的 主 从 复制 方式 基本 上 就 能 满足 需求 了 。 


解决 高 并 发 问题 的 架构 


线程 复制 可 以 满足 需求 ， 则 不 推荐 并 发 复制 的 方式 。 


局 ?前面 我 们 已 经 说 到 ， 在 架构 设计 上 需要 秉承 简单 快捷 的 原则 ， 参 考 MySQL 复 制 的 设 


F 复 制 的 原理 ，ASP 架 构 也 是 有 上 述 三 种 复制 模式 


架构 都 可 视 为 ASP 的 衍生 架构 。 由 于 


的 主 从 复制 高 可 上 


ASP (Active Standby Pair) 架构 是 一 种 基于 复制 技术 ， 最 典型 、 最 常 上 


架构 ， 其 他 的 高 可 F 


的 。 但 需要 注意 的 是 ， 当 为 缓存 集合 建立 ASP 架 构 时 ， 是 不 支持 SWT 缓 存 集合 和 自 定义 缓存 集合 的 ，TimesTen 是 无 法 在 保证 缓存 集合 到 Oracle 同 步 刷 新 的 同时 ， 又 进行 Active 到 standby 的 数据 复制 。 换 而 


只 读 缓存 集合 和 AWT 缓 存 集合 。 


言 之 ， 如 果 需 要 保证 主 从 复制 的 高 可 用 架构 ， 就 只 能 使 


前 面 说 到 ， 在 复制 方式 实现 上 ， 选 择 异 步 复 制 是 一 个 不 错 的 选择 。 如 


6-10 所 示 ， 在 ASP 的 架构 设计 中 ， 选 择 Active 和 Standby 进 行 异步 复制 来 进行 配 
的 ， 而 SWT 缓 存 集合 和 自 定义 缓存 集合 可 以 存在 于 Active 库 中 ， 但 需要 排除 在 ASP 的 异步 复制 架构 之 外 。 


。 异 步 复制 是 基于 缓存 集合 来 进行 的 ， 对 于 只 


读 缓存 集合 、AWT 缓 存 集合 、TimesTen 独 立 表 都 是 支持 


应 用 
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图 6-10 ” ASP 架构 原理 图 


对 于 只 读 缓存 集合 ,数据 从 Oracle 


而 ，AWT 缓 存 集合 是 需要 注意 的 ， 在 Active 发 起 的 数据 不 再 直接 刷新 到 Oracle， 而 是 先 异 步 复制 到 standby， 再 由 Standby 衍 化 刷新 到 Oracle。 


自动 刷新 到 Active 库 ， 再 异步 复制 到 Standby 库 ， 相 对 比较 简单 ， 而 TimesTen 的 独立 表 与 Oracle 没 有 任何 关联 ， 也 仅 在 Active 和 Standby 之 间 实 现 异 步 复 制 。 然 


虽然 到 Oracle 的 数据 库 可 能 存在 延 时 ， 但 是 将 刷新 的 操作 交 


由 Standby 去 完成 ， 也 降低 了 Active 的 压力 。 对 于 应 用 来 说 ， 一 些 时 效 要 求 很 高 的 可 以 连接 到 Active， 而 时 效 要 求 较 低 的 则 可 以 连接 到 Standby，Active 和 Standby 都 是 可 以 对 外 提供 服务 的 ， 但 是 AWT 缓 存 


集合 在 Standby 上 只 提供 只 读 服务 。 


1.ASP 架 构 创建 


下 面 我 们 通过 一 个 实例 介绍 ， 具 体 展示 一 下 如 何 给 TimesTen 实 例 ttalex 扩 


步骤 1 如 6.2.1 节 和 6.2.2 节 所 述 ， 在 新 的 节点 上 安装 TimesTen 软 件 ， 并 完成 实例 参数 和 进程 参数 的 配 


所 示 : 


展 一 个 standby 节 点 tsalex。 


， 但 不 要 创建 实例 。 需 要 注意 的 是 ， 在 sys.odbc.ini 参 数 配置 上 需要 将 ttalex 修 改 为 tsalex， 如 下 


[tsalex] 
Driver=/app/oracle/ttalex/TimesTen/tsalex/lib/libtten.so 
DataStore=/DataStore/tsalex/tsalex 


步骤 2 在 Active 端 (ttalex) 暂停 缓存 集合 的 自动 刷新 功能 。 


$ttIsql DSN=ttalex;UID=cacheuser; PWD=cacheuser;oraclePWD=cacheuser;" 
Command> alter cache group cacheuser.cg readonly 601 set 
> autorefresh state paused; 


管理 员 方 式 登 录 ttalex， 关 闭 复制 代理 ， 再 创建 ASP 服 务 。 如 下 所 示 ，ttalex 为 Active 端 


， 对 应 了 


机 名 为 myactive，tsalex 为 Standby 端 ， 对 应 主机 名 为 mystandby。 


$ ttIsql ttalex 

Command> call ttRepStop; 

Command> create active standby pair ttalex on myactive, 
> tsalex on mystandby; 


很 遗憾 的 是 ， 我 们 的 创建 过 程 报错 了 ， 报 错 内 容 如 下 所 示 : 


17036: SYNCHRONOUS WRITETHROUGH cache groups cannot be replicated in 
an ACTIVE STANDBY scheme. Either DROP or EXCLUDE the cache group for 
table ALEX.TT SWT 601 

The command failed. 


因为 实例 中 存在 ASP 所 不 支持 的 SWT 缓 存 集合 ， 需 要 删除 掉 ， 或 者 通过 如 下 方式 将 其 排除 在 新 建 的 ASP 架构 之 外 。 


Command> create active standby pair ttalex on myactive, 
> tsalex on mystandby 
> exclude cache group cacheuser.cg swt 601; 


步骤 4 ” ”ASP 创建 完 成 之 后 ， 就 可 以 打开 复制 代理 了 ， 并 且 将 ttalex 节 点 的 实例 角色 设置 为 “Active”， 示 例如 下 : 


Command> call ttRepStart; 

Command> call ttRepStateSet ('ACTIVE'); 
Command> call ttRepStateGet; 

< ACTIVE, NO GRID > 

1 row found. 


步骤 5 ”至 此 ，Active 端 的 配置 已 经 完成 ， 可 以 转 到 Standby 端 进行 配置 。 此 时 ，Standby 还 没有 实例 存在 ， 通 过 如 下 命令 ， 从 Active 端 复制 ttalex 实 例 到 Standby 端 ， 并 启动 为 tsalex 实 例 ， 示 例如 下 : 


$ ttRepAdmin -duplicate -from ttalex -host cnsh230235 -keepCG -uid alextt -cacheuid cacheuser -connStr "dsn=tsalex" 


ttRepAdmin 命 令 的 相关 参数 说 明 ， 可 以 使 用 “ttRepAdmin-help” 命 令 参看 。 


步骤 6 接 下 来 ， 跟 Active 端 操作 一 样 ， 将 新 复制 的 tsalex 实 例 设置 为 “Standby” 的 角色 ， 示 例如 下 : 


$ ttIsql tsalex 

Command> call ttRepStart; 
Command> call ttRepStateGet; 
< STANDBY, NO GRID > 

1 row found. 


进行 如 上 操作 后 ，ASP 架 构 就 已 经 配置 完成 了 ， 可 以 进行 一 下 连通 性 测试 : 
“ 在 各 个 节点 上 ， 对 于 各 个 缓存 集合 和 独立 表 进 行 查询 ， 验 证 数据 一 致 性 ; 
“ 针对 只 读 缓存 集合 ， 在 Ortacle 进 行 插入 操作 ， 在 Active 和 Standby 进 行 查询 ， 验 证 三 个 节点 的 数据 一 致 ; 
“ 针对 AWT 缓 存 集 合 ， 在 Active 进 行 插入 操作 ， 在 Standby 和 Oracle 进 行 查询 验证 ; 
“ 针对 TimesTen 独 立 表 ， 只 需要 在 Active 和 Standby 进 行 验证 ， 该 验证 也 可 以 用 来 监控 和 标志 复制 代理 的 运行 状态 。 
2.Switchover 切 换 


对 于 ASP 的 高 可 用 架构 来 说 ， 它 与 Oracle 的 Data Guard 一 样 是 支持 灵活 的 角色 切换 (Switchover) 和 故障 切换 (Failover) 的 。 我 们 先 来 看 一 下 角色 切换 是 如 何 进行 的 。 


步骤 1 同样 ， 需 要 在 Active 端 进行 验证 ， 先 暂停 缓存 集合 的 自动 刷新 ， 断 开 与 Oracle 的 数据 刷新 。 然 后 ， 调 用 内 置 存 储 过 程 ttRepSubscriberWait 判 断 是 否 有 事务 积压 : “00” 表 示 所 有 的 事务 都 已 经 
复制 到 Standby 了 ; “01” 则 表示 还 存在 未 复制 的 事务 。 如 果 返 回 结果 为 “01”， 则 需要 等 待 事务 复制 完成 。 示 例如 下 : 


Command> alter cache group cacheuser.cg readonly 601 set 
> autorefresh state paused; 

$ ttIsql ttalex 

Command> call ttRepSubscriberWait (,,,,5); 

* D0 

1 row found. 


内 置 存储 过 程 ttRepSubscriberWait 相 关 参 数 说 明 如 表 6-5 所 示 。 


表 6-5 ”ttRepSubscriberWait 相 关 参 数 说 明 


参 数 类 型 说 明 


replicationName TT CHAR (30) 待 复 制 SCHEMA 名 称 ，NULL 表示 全 部 
replicationOwner TT CHAR (30) 待 复 制 SCHEMA 的 属 主 ，NULL 表示 全 部 
( 续 ) 


参数 类 型 说 明 


subscriberStoreName TT VARCHAR (200) 待 操作 从 库 名 称 ，NULL 表示 全 部 
subscriberHostName TT_VARCHRR (200) 待 操作 从 宽 主 机 名 ，NULL 和 
waitTime TT_INTEGER NOT NULL 操作 等 待 时 间 的 秒 数 ,“-1” 表 示 持 续 等 待 


步骤 2 接 下 来 在 Active 端 关闭 缓存 代理 和 复制 代理 服务 ， 并 调用 内 置 存储 过 程 ttRepDeactivate 取 消 实例 “Active” 的 角色 ， 示 例如 下 : 


Command> call ttCacheStop; 
Command> call ttRepStop; 
Command> call ttRepDeactivate; 
Command> call ttRepStateGet; 
< IDLE, NO GRID > 

1 row found. 


步骤 3 下 一 步 想必 大 家 都 能 想到 了 ， 将 原来 “Standby” 转 换 为 新 的 “Active” 角 色 。 同 时 ， 在 新 的 Active 端 开启 缓存 代理 ， 使 之 与 Oracle 交 互 。 


Command> call ttCacheStart; 

Command> call ttRepStateSet ('ACTIVE'); 
Command> call ttRepStateGet; 

< ACTIVE, NO GRID > 

1 row found. 


步骤 4 ”最 后 ,将 被 置 为 “IDLE” 的 原 Active 的 复制 代理 重新 开启 ， 则 自动 识别 为 新 的 “Standby” 角 色 ， 示 例如 下 : 


Command> call ttRepStart; 
Command> call ttRepStateGet; 
< STANDBY, NO GRID > 

1 row found. 


至 此 ， 我 们 就 成 功 完成 了 一 次 ASP 实 例 的 角色 切换 工作 。 对 于 角色 切换 来 说 ， 其 前 提 是 需要 保证 Active 和 Standby 都 是 健康 运行 状态 的 ， 只 是 为 了 满足 硬件 维护 、 实 例 迁 移 等 需要 转换 二 者 的 角色 而 已 ， 
操作 期 间 实 例 都 是 可 用 的 。 


3.Failover 切 换 


故障 切换 相对 来 说 要 简单 一 些 ， 只 需要 控制 一 个 角色 的 变换 即 可 。 如 果 是 Active 节 点 出 现 故 障 ， 就 需要 将 Standby 节 点 切换 成 新 的 Active 节 点 。 使 用 管理 员 账 户 连接 到 Standby 实 例 ， 将 其 角色 设置 
为 “Active” ， 再 调用 内 置 存储 过 程 ttRepStateSave 将 原 Active 节 点 的 ttalex 实 例 设置 为 FAILED， 最 后 为 只 读 缓存 集合 开启 缓存 代理 服务 即 可 。 步 又 如 下 所 示 : 


$ ttIsql ttalex 

Command> call ttCacheStart; 

Command> call ttRepStateSet ('ACTIVE'); 

Command> call ttRepStateSave('FAILED', 'ttalex', 'myactive'); 
Command> call ttRepStateGet; 

< ACTIVE, NO GRID > 


如 果 出 现 故障 的 是 standby 节 点 ， 那 么 AWT 缓 存 集合 到 Oracle 的 衍生 复制 就 会 受到 影响 ， 需 要 在 Active 实 例 上 将 Standby 节 点 设置 为 FAILED， 步 骤 如 下 所 示 : 


$ ttIsql ttalex 
Command> call ttRepStateSave('FAILED', 'tsalex', 'mystandby'); 


内 置 存储 过 程 ttRepStateSave 相 关 参 数 说 明 如 表 6-6 所 示 。 


表 6-6 ttRepStateSave 相 关 参 数 说 明 


参 。 数 类 型 说 明 


state TT_VARCHAR (20) 待 操 作 数 据 库 的 目标 状态 ， 目 前 仅 可 以 设置 为 “FAILED”， 用 于 
数据 库 出 现 故障 时 ， 标 示 其 为 不 可 用 状态 
storeName TT VARCHAR (200) 待 操作 数据 库 实 例 名 称 
hostName TT VARCHAR (200) 待 操作 数据 库 实例 主机 名 
4. 自 动 故 障 切 换 


在 6.1.3 节 中 ， 我 们 提 到 TimesTen 的 连接 方式 可 以 分 为 Direct 模 式 和 C/S 模 式 。 对 于 C/S 连 接 模 式 来 说 ，TimesTen 是 能 够 支持 自动 故障 切换 功能 的 。 当 发 生 Switchover 或 者 Failover 的 时 人 息 ,， 使 用 C/S 模 
式 连接 的 客户 端 是 可 以 从 原 Active 节 点 自动 切换 到 新 的 Active 节 点 的 ， 而 不 会 发 生 连 接 中 断 的 现象 。 


(1) C/S 连 接 模式 的 自动 故障 切换 配 


在 开始 展示 之 前 ， 我 们 先 要 进行 C/S 连 接 模式 的 自动 故障 切换 配置 ， 配 置 过 程 需要 同时 在 Active 节 点 和 Standby 节 点 进行 ， 示 例如 下 : 


“sys.ttconnect.ini 配 置 文件 中 添加 以 下 信息 ， 配 置 Active 节 点 和 Standby 节 点 的 主机 名 和 连接 端口 号 : 


[ttalex cs] 
Description=TimesTen Server 
Network Address=myactive 
TCP_ PORT=53335 

[tsalex_cs] 
Description=TimesTen Server 
Network Address=mystandby 
TCP_PORT=53335 


“ sys.odbc.ini 配 置 文件 中 添加 以 下 信息 ， 将 Active 设 置 为 主 服务 器 (TTC_SERVER) ，Standby 设 置 为 备 服务 器 (TTC_SERVER2) 。 黑 认 情 况 下 ， 客 户 端 连接 的 是 ttalex_cs， 当 其 不 可 用 时 ， 则 连接 


tsalex_cso 


[alex cs] 

TTC_SERVER=ttalex_cs 

TTC_ SERVER DSN=ttalex 

TTC Timeout=10 
DatabaseCharacterSet=2ZHS16GBK 
TTC_SERVER2=tsalex_cs 
TTC_SERVER DSN2=tsalex 


(2) 模拟 Switchover 对 客户 端 连接 的 影响 


接 下 来 模拟 Switchover 对 客户 端 连接 的 影响 ， 客 户 端 连接 如 下 所 示 : 


$ ttisqlcs "dsn=alex cs;uid=cacheuser;password=cacheuser;oraclepwd=cacheuser™" 


默认 情况 下 ， 客 户 端 连接 到 了 Active 节 点 ， 通 过 ttstatus 监 控 到 该 连接 ， 同 时 其 衍生 出 一 个 Failover 的 服务 器 连接 ， 该 连接 就 是 用 于 自动 故障 切换 的 。 需 要 注意 的 是 ， 配 置 好 自动 故障 切换 功能 后 ， 每 新 
建 一 个 客户 端 连 接 ， 则 都 会 衍生 出 一 个 对 应 的 Failover 服 务 器 连接 ， 也 就 是 说 会 导致 连接 数 翻 番 。 监 控 结果 如 下 所 示 : 


$ ttstatus 
Type PID Context Connection Name ConnID 
Server 20326 0x00000000123c33e0 alex cs 号 
(Client Information: pid: 20303; IPC: TCP/IP; 
Node: cnsh230235 (10.31.9.242)) 
Process 20326 0x000000001248e9f0 Failover 9 


当 Switchover 操 作 进 行 时 ， 即 原 Active 实 例 调用 ttRepDeactivate 操 作 ， 实 例 进 入 IDLE 状 态 ， 已 经 连接 的 客户 端 将 无 法 执行 DML 操 作 ， 但 查询 操作 不 受 影响 ， 同 时 不 允许 新 建 连接 ， 因 为 无 Active 节 


点 。 当 新 Active 实 例 切 换 后 ，Switchover 操 作 结 束 ， 客 户 端 连 接 恢复 正常 。 


然而 ， 值 得 注意 的 是 ， 由 于 配置 了 自动 故障 切换 ，Switchover 过 程 中 ， 上 述 “pid: 20303” 进 程 并 不 会 中 断 ， 当 完成 Switchover 之 后 ， 该 进程 在 原 Active 节 点 上 无 法 监控 到 ， 而 是 被 自动 切换 到 了 新 的 


Active 实 例 上 。 此 时 ，OSs 的 进程 ID 虽然 发 生 了 改变 ， 但 是 客户 连接 的 pid 并 未 发 生变 化 ， 仍 为 20303， 标 志 该 连接 并 未 发 生 中 断 ， 监 控 结果 如 下 所 示 : 


$ ttstatus 
Type BID Context Connection Name ConnID 
Server 2 并 Ox000000001ad763e0 alex cs 8 


(Client Information: pid: 20303; IPC: TCP/IP; 
Node: cnsh230235 (10.31.9.242)) 
Process 12521 Ox000000001ae3e480 Failover Ei 


如 果 是 发 生 Failover 的 操作 呢 ? 因为 Active 实 例 不 可 用 了 ， 此 时 同样 禁止 新 建 连 接 ， 已 连接 的 客户 端 将 无 法 进行 任何 操作 ， 即 使 是 查询 操作 ， 同 样 会 报错 ， 信 息 如 下 所 示 : 


Command> select * from alex.tt awt 601; 
47137: Statement handle invalid due to client failover 
The command failed. 


只 有 当 新 Active 实 例 完 成 角色 切换 后 ， 客 户 端 连接 才 恢复 正常 。 跟 Switchover 操 作 一 样 ， 已 连接 的 客户 端 自动 完成 到 新 Active 实 例 的 切换 ， 连 接 的 pid 仍 为 20303 不 变 。 监 控 结 果 如 下 : 


$ ttstatus 
Type PID Context Connection Name ConnID 
Server 5449 0x0000000009cf83e0 alex cs 2 


(Client Information: pid: 20303; IPC: TCP/IP; 
Node: cnsh230235 (10.31.9.242)) 
Process 5449 0x00002aaac8014330 Failover 车 


综 上 所 述 ， 虽然 TimesTen 能 够 提供 C/S 连 接 的 字段 故障 切换 功能 ， 但 是 ASP 的 异步 复制 架构 不 可 避免 会 出 现 短暂 的 事务 日 志 堆 积 ， 进 行 Failover 时 还 是 需要 人 工 判 断 的 ， 自 动 切换 不 是 一 个 很 稳妥 的 做 


6.5 ”高 可 用 网 格 架 构 


架 


在 建 库 的 时 候 ， 我 们 提 到 过 一 个 网 格 的 概念 ， 这 也 是 Oracle 网 格 技术 在 TimesTen 中 的 体现 。 在 TimesTen 数 据 库 中 架构 网 格 ， 可 以 实现 类 似 于 Oracle 数 据 库 的 RAC 高 可 用 架构 ， 其 也 是 TimesTen 高 可 上 


R 构 的 一 种 实现 方式 。 


在 RAC 架 构 中 ， 通 过 扩展 多 个 实例 来 实现 数据 库 的 负载 均衡 ， 但 比较 遗憾 的 是 ， 因 为 多 个 实例 对 应 的 数据 库 只 有 一 套 ， 所 以 高 并 发 的 问题 很 难 通过 这 种 架构 解决 。 面 对 高 并 发 问题 ，RAC 的 负载 均衡 作 


格 


6. 


不 大 ， 更 大 的 作用 是 元 余 实 例 ， 实 现 高 可 用 。 而 在 TimesTen 的 网 格 架构 中 ， 每 个 节点 都 有 独立 的 内 存 区 域 和 检查 点 文件 等 ， 可 以 说 每 个 节点 都 是 完全 独立 的 ， 它 更 像 是 一 个 分 布 式 的 数据 库 体系 ， 通 过 网 
服务 实现 相互 闻 的 数据 一 致 性 。 因 此 ，TimesTen 的 网 格 架构 在 解决 高 并 发 、 实 现 负载 均衡 上 是 有 一 定 作用 的 。 


我 们 这 里 所 说 的 网 格 架构 ， 严 格 来 说 应 该 称 为 缓存 网 格 (Cache Grid) 架构 ， 它 是 一 组 IMDB 节点 的 集合 ， 每 一 个 节点 都 是 一 个 网 格 成 员 ， 缓 存 网 格 具 有 以 下 特点 : 
“ 一 个 缓存 网 格 可 以 包含 一 个 或 者 多 个 成 员 ; 


: 每 个 成 员 缓存 的 内 容 都 是 按照 一 定 关联 的 数据 模型 组 织 起 来 的 ， 也 就 是 缓存 集合 的 形式 ， 所 不 一 样 的 是 在 缓存 网 格 中 ， 必 须 是 全 局 性 的 缓存 集合 形式 ; 


“ 网 格 成 员 间 通 过 点 对 点 协议 相互 连接 ; 

“ 网 格 所 有 成 员 必须 从 相同 的 Oracle 数 据 库 中 缓存 表 ; 

“ 缓存 数据 跨 成 员 节 点 动态 分 布 ， 其 访问 由 应 用 端 控制 ; 
“ 缓存 网 格 成 员 间 保证 数据 一 致 性 ; 


“ 缓存 网 格 目前 只 支持 AWT 缓 存 集合 。 


5.1 无 网 格 双 活 架构 


在 开始 介绍 缓存 网 格 架构 之 前 ， 我 们 先 来 设想 一 下 ， 在 没有 网 格 服务 的 情况 下 ， 我 们 如 何 来 实现 双 活 (Active-Active) 的 负载 均衡 呢 ? 如 图 6-11 所 示 ， 我 们 架构 了 两 个 完全 独立 的 Active 实 例 ， 均 对 同 


一 个 Oracle 数 据 库 表 tt_awt_601 创 建 了 AWT 缓 存 集合 。 


3) 行 ID=1， 
NAME 从 aaa 
更 新 为 ccc 


山手 工 刷新 


@ 行 ID=1， 
NAME 从 aaa 
更 新 为 ddd 


tt awt 601 证 awt 601 


出 衍化 刷新 
(ID=1) 


© 衍化 刷新 
(ID=1) 


2 手工 刷新 


tt awt 601 


图 6-11 无 限制 双 活 架构 图 


通过 以 下 一 些 步骤 来 验证 一 下 吧 : 


@ 左 库 从 Oracle 库 手工 刷新 数据 ， 表 tt_awt_601 中 的 两 条 记录 均 被 加 载 到 左 库 ; 


@ 同 样 的 方法 ， 右 库 也 从 Oracle 手 工 加 载 ， 同 样 的 两 条 记录 也 被 加 载 到 右 库 中 ; 


@ 在 左 库 中 ， 更 新 ID=1 的 行 ，NAME 字 段 从 “aaa” 更 新 为 “ccc”; 


@ 左 库 的 更 新 结果 ， 被 自动 衍化 刷新 到 Oracle 库 ， 此 时 Oracle 库 中 ，ID=1 行 的 NAME 字 段 也 被 更 新 为 “ccc”; 


@@ 此 时 在 右 库 中 ，ID=1 行 的 NAME 字 段 仍 为 “aaa”， 没 有 同步 更 新 (除非 在 手工 刷新 ) ， 同 样 的 操作 也 在 右 库 中 进行 ， 更 新 ID=1 行 的 NAME 字 段 为 “ddd”; 


@ 右 库 的 更 新 结果 同样 被 自动 衍化 刷新 到 Oracle 库 ， 此 时 在 Oracle 库 中 ID=1 行 的 NAME 字 段 变 成 “ddd” 了 ， 然 而 左 库 仍 为 “ccc”， 且 认为 Oracle 中 也 为 “ccc”， 这 样 三 个 库 之 间 的 数据 不 一 致 就 形 


成 了 。 


6.5.2 ”网 格 双 活 架构 


TimesTen 的 缓存 集合 对 Oracle 表 的 缓存 ， 是 没有 排他 限制 的 ， 多 个 TimesTen 库 可 以 同时 对 同一 个 Oracle 库 的 同一 个 表 进 行 缓存 ， 互 相间 相对 独立 ， 且 支持 所 有 缓存 集合 类 型 。 对 于 只 读 缓存 集合 来 
说 ， 这 是 完全 没有 问题 的 ， 甚 至 是 一 件 好 事情 ， 但 是 对 于 其 他 支持 读 写 操 作 的 缓存 集合 却 是 有 害 的 。 在 没有 排他 限制 的 分 布 式 缓存 中 ， 是 会 完全 丧失 数据 一 致 性 的 。 


然而 ， 实 现 完全 的 排他 限制 ， 就 无 法 实现 分 布 式 存储 了 ， 所 谓 使 用 双 活 架构 来 进行 负载 均衡 就 不 可 能 实现 了 。 这 里 ， 我 们 可 以 回顾 一 下 前 面 讲 到 过 的 分 布 式 数据 库 的 CAP 理 论 ， 对 此 就 不 难 理解 了 。 对 
于 TimesTen 数 据 库 来 说 ， 是 一 个 要 求 保证 数据 强 一 致 性 的 关系 型 数据 库 ， 其 事务 隔离 级 别 也 是 与 Oracle 保 持 一 致 的 ， 那 如 何在 分 布 式 存储 上 实现 数据 一 致 性 呢 ? 还 是 需要 进行 排他 限制 的 ， 但 不 是 缓存 集合 
级 别 的 排他 ， 而 是 其 中 表 的 行 级 排他 。 这 也 是 缓存 网 格 架构 的 基本 实现 原理 。 


接 下 来 ， 我 们 来 看 一 下 缓存 网 格 架构 是 如 何 来 实现 双 活 负载 均衡 的 吧 。 如 图 6-12 所 示 ， 其 基本 架构 与 上 述 情况 是 一 样 的 ， 唯 一 的 区 别 在 于 将 TimesTen 的 两 个 库 放置 到 了 同一 个 缓存 网 格 中 。 


(0) 行 ID=1， 
NAME 从 aaa 
更 新 为 abc 


(8 更 新 行 ID=1， 
报错 


3 插入 操作 


tt awt 601 tt awt 601 


Te 


2 


s (DOLOAD 刷 新 

ODLOAD 刷 新 : > (无 记录 获取 ) 
(获取 ID=1，2) : tt awt 601 : 四 LOAD 刷新 
5LOAD 刷 新  。 > (获取 ID=3) 
(无 记录 获取 ) : 。 (DOLOAD 刷 新 


[ 站 放 让 玫 于 放下 让 WE (无 记录 获取 ) 


6-12 ”缓存 网 格 双 活 架 构图 


上 述 同样 的 操作 在 以 下 架构 中 会 有 什么 不 一 样 呢 ? 验证 步骤 如 下 : 
@ 初 始 状态 下 ，Oracle 库 有 两 行 (ID=1，2) 记录 ，TimesTen 左 右 两 库 均 为 空 ， 在 左 库 中 手工 LOAD 刷 新 (缓存 网 格 不 支持 REFRESH 刷 新 方式 ) ，Oracle 库 中 的 两 行 记录 被 加 载 到 左 库 ; 


@ 再 于 右 库 中 进行 同样 的 手工 加 载 ， 则 没有 任何 记录 被 获取 ， 因 为 ID=1，2 的 两 行 记录 都 被 加 载 到 左 库 ， 则 在 同一 网 格 中 ， 被 标示 为 左 库 独 有 ， 对 其 他 网 格 成 员 排他 ; 


@ 应 用 再 插入 一 行 新 记录 (ID=3) 到 Oracle 库 ， 该 记录 为 空闲 状态 ， 未 被 任何 网 格 成 员 独 占 ; 


@ 右 库 再 触发 一 次 手工 刷新 ， 因 为 ID=3 的 行 没有 被 任何 成 员 独 占 ， 被 加 载 到 右 库 中 ; 


加 此 时 左 库 触发 一 次 手工 刷新 ， 与 右 库 第 一 次 加 载 操作 一 样 ， 无 记录 获取 ， 在 Oracle 中 保存 了 全 量 的 数据 ， 而 ID=1，2 被 左 库 独 占 ， 右 库 不 可 见 ，ID=3 被 右 库 独占 ， 左 库 不 可 见 ; 
@ 在 左 库 中 ， 更 新 ID=1 的 行 ，NAME 字 段 从 “aaa” 更 新 为 “abc”; 
@ 左 库 的 更 新 结果 ， 被 自动 衍化 刷新 到 Oracle 库 ， 此 时 Oracle 库 中 ，ID=1 行 的 NAME 字 段 也 被 更 新 为 “abc” ; 


@@ 在 右 库 中 ， 如 果 再 更 新 ID=1 行 的 NAME 字 段 为 “ddd” ， 则 会 报错 ， 因 为 ID=1 的 行为 左 库 独 占 ; 


@ 因 为 ID=1 的 行 被 左 库 更 新 过 了 ， 再 于 右 库 手 工 加 载 一 次 ， 仍 没有 记录 被 获取 ，ID=1 的 行 仍 为 左 库 独 占 。 


可 以 看 到 ， 借 助 于 缓存 网 格 的 控制 ， 在 各 个 网 格 成 员 间 保 证 了 数据 的 一 致 性 ， 达 成 了 负载 均衡 的 目的 。 然 而 ， 各 成 员 之 间 的 数据 路 由 是 由 Oracle 库 和 TimesTen 库 中 的 数据 字典 来 控制 的 ， 仍 有 可 能 在 并 
发 处 理 压力 大 的 时 候 ， 出 现 单 点 争 用 ， 导 致 整体 并 发 处 理 能 力 下 降 。 


先 通过 一 个 实例 来 演示 一 下 如 何 创建 缓存 网 格 吧 ， 具 体 步骤 如 下 : 


步骤 1 在 Oracle 端 创建 一 个 用 以 缓存 的 表 tt_gawt_ 602， 并 初始 化 插入 3 行 记录 。 示 例如 下 : 


SQL> create table alex.tt gawt 602 (id number primary key, 
2 name varchar2(100)); WW 

SQL> insert into alex.tt gawt 602 values (1,'aaa'); 

SQL> insert into alex.tt gawt 602 values (2,'bbb'); 

SQL> insert into alex.tt gawt 602 values (3,'ccc'); 

SQL> commit; 


步骤 2 重建 ttalex01 和 ttalex02 两 个 TimesTen 库 ， 使 其 成 为 两 个 独立 的 实例 ， 并 参照 6.2.4 节 的 步骤 ， 分 别 配置 成 缓存 实例 ， 但 缓存 网 格 的 创建 仅 在 ttalex01 上 创建 即 可 ， 示 例如 下 : 


$ ttIsql "DSN=ttalex01;UID=cacheuser; PWD=cacheuser;oraclePWD=cacheuser;" 
Command> call ttGridCreate('myGrid'); 
Command> call ttGridNameSet ('myGrid'); 


步骤 3 分别 在 两 个 TimesTen 库 创建 同名 的 全 局 AWT 缓 存 集合 ， 且 缓存 同一 个 Oracle 表 ，SQL 语 句 如 下 所 示 : 


Command> create asynchronous writethrough global cache group 
> cacheuser.cg gawt 602 from 
> alex.tt gawt 602 (id number primary key, name varchar2(100)); 


步骤 4 分 别 在 两 个 库 上 调用 内 置 存储 过 程 ttGridAttach， 将 其 加 入 到 myGrid 缓 存 网 格 中 ， 如 下 所 示 ， 则 两 个 库 都 作为 独立 的 成 员 节 点 存在 于 同一 网 格 中 ， 步 骤 3 创 建 的 全 局 AWT 缓 存 集合 ， 将 在 两 个 


成 员 节点 间 实 现 共享 。 


@ttalex01 库 上 执行 : 


Command> call ttGridAttach (1, 'ttalex01', 'myactive01',53335); 


@ttalex02 库 上 执行 : 


Command> call ttGridAttach (1, 'ttalex02', 'myactive02',53335); 


@ 完 成 后 可 以 在 任意 节点 查询 到 节点 状态 信息 ， 如 下 : 


Command> call ttGridNodeStatus; 
< MYGRID, 1, 1, T, myactive01, MYGRID ttalex01 1, ... > 
< MYGRID, 3, 1, T, myactive02, MYGRID ttalex02 3, .... > 


内 置 存储 过 程 ttGridAttach 相 关 参 数 说 明 如 表 6-7 所 示 。 


表 6-7 ttGridAttach 相 关 参 数 说 明 


类 型 说 上 朋 
> TY TINTEGER NOT 加 于 节点 的 数据 库 类 型 ， 
口 1 - 独立 库 或 Active 库 
口 2 - Standby 库 


namel TT VARCAR (30) 独立 库 或 Active 库 的 名 称 
IPAddr1 TT VARCHAR (128) NOT NULL 独立 库 或 Active 库 IP 地 址 
port1 TT INTEGER NOT NULL 独立 库 或 Active 库 连接 端口 号 
name2 TT VARCAR (30) Standby 库 的 名 称 

IPAddr2 TT VARCHAR (128) NOT NULL Standby 库 IP 地 址 

port2 T_ INTEGER NOT NULL Standby 库 连 接 端 口号 


需要 注意 的 是 ， 缓 存 集合 中 的 主键 值 是 不 能 被 更 新 的 ， 但 是 在 Oracle 端 是 可 以 更 新 的 。 当 Oracle 端 更 新 主键 之 后 ，TimesTen 端 必须 要 全 量 刷新 (Refresh) 来 保证 数据 一 致 性 ， 增 量 刷 新 (Load) 则 会 
将 被 更 新 的 主键 值 识别 为 一 个 新 的 主键 值 ， 重 新 加 载 到 缓存 集合 中 ， 导 致 TimesTen 对 同一 记录 保存 了 新 旧 两 个 版 本 的 主键 值 ， 数 据 不 一 臻 产生。 然而， 缓存 网 格 中 的 全 局 AWT 缓 存 集合 是 不 允许 全 量 刷新 
的 ， 所 以 必须 严格 控制 不 能 在 Oracle 端 进行 主键 键 值 更 新 。 


如 下 例 所 示 ， 在 任 一 缓存 网 格 成 员 进行 手工 加 载 (初始 化 增 量 加 载 等 同 于 全 量 加 载 ) ，3 行 记录 都 被 成 功 加 载 。 然 后 ， 在 Oracle 端 更 新 主键 ，ID=1 更 新 为 ID=101， 再 于 TimesTen 手 工 增 量 加 载 ， 发 现 
仍 有 1 行 记录 被 加 载 ， 查 询 结果 中 TimesTen 的 表 多 出 1 行 记录 。 


Command> load cache group cacheuser .cg gawt 602 commit every 0 rows; 
3 cache instances affected. 本 加 

Command> select * from alex.tt gawt 602; 

< 1，aaa > 加 

< 2，bbb > 

二 号 CE 务 

SQL> update alex.tt gawt 602 set id=101 where id=17 

SQL> commit; 

Command> load cache group cacheuser.cg gawt 602 commit every 0 rows; 
1 cache instance affected. 

Command> select * from alex.tt gawt 602; 

<1, aaa> 于 

< 2; bbb > 

< 3，ccc > 

< 101，aaa > 


细心 的 读者 看 到 这 里 ， 应 该 会 提出 另外 一 个 问题 : “1 行 记录 一 旦 被 某 个 成 员 独 占 了 ， 是 不 是 其 他 成 员 就 完全 没有 办 法 再 获取 了 ?”” 答案 是 否定 的 ， 当 1 行 记录 被 某 个 成 员 独占 后 ， 其 他 成 员 是 无 法 再 从 
Oracle 端 加 载 获取 了 ， 但 是 可 以 通过 网 格 服务 从 独占 节点 “夺取 ”独占 权 。“ 和 夺取 ”方式 和 动态 缓存 集合 的 动态 加 载 方式 非常 类 似 ， 都 是 通过 主键 等 值 查询 来 实现 的 。 


下 面 是 一 个 演示 的 例子 ，Oracle 表 中 3 行 记 录 都 被 ttalex01 节 点 独占 了 ， 此 时 在 ttalex02 上 执行 从 Oracle 手 工 加 载 是 没有 任何 记录 被 加 载 的 。 当 发 生 ID= 1 的 主键 查询 时 ，ID= 1 行 的 独占 权 被 成 功 转 移 到 
ttalex02 上 ，ttalex01 失 去 独占 权 ， 即 使 再 次 从 Oracle 加 载 也 是 无 法 获取 的 。 


GOttalex01 上 执行 : 


Command> select * from alex.tt gawt 6027 
< 1 daa > 

< 2 bbb > 

~ WO 

3 rows found. 


@ttalex02 上 执行 : 


Command> load cache group cacheuser.cg gawt 602 commit every 0 rows; 
0 cache instances affected. 

Command> select * from alex.tt gawt 602; 

0 rows found. 

Command> select * from alex.tt gawt 602 where id=17 

<1, aaa> 

1 row found. 

Command> select * from alex.tt gawt 602; 

<1, aaa> 

1 row found. 


@ttalex01 上 执行 : 


Command> select * from alex.tt gawt 602; 

< 2, bbb > 站 加 

< 3，ccc > 

2 rows found. 

Command> load cache group cacheuser.cg gawt 602 commit every 0 rows; 
0 cache instances affected. 


当然 ， 我 们 也 可 以 创建 动态 的 全 局 AWT 缓 存 集合 ， 虽 然 同样 解决 不 了 主键 键 值 更 新 引起 的 冲突 问题 ， 但 其 可 以 帮助 我 们 解决 另 一 个 问题 。 从 上 述 例子 可 以 看 到 ，ID=1 行 被 ttalex02 独 占 ，ID=2 和 ID=3 
行 被 ttalex01 独 占 ， 如 果 此 时 ttalex01 节 点 从 网 格 中 删除 了 ， 那 么 ID=2 和 ID=3 行 将 何去何从 呢 ? 通过 下 面 一 个 例子 来 分 析 一 下 吧 。 


从 网 格 中 剔除 ttalex01 节 点 ，ttalex01 节 点 上 的 全 局 AWT 缓 存 集合 被 自动 卸载 。 在 ttalex02 节 点 上 再 进行 主键 等 值 查询 ， 无 法 再 获取 ID=2 和 ID=3 的 记录 。 因 为 此 两 行 记录 被 置 为 空闲 状态 ， 主 键 等 值 查 
询 只 能 在 网 格 节点 之 间 “ 和 夺取 ”独占 权 ，ttalex01 节 点 不 存在 后 ，ttalex02 节 点 将 无 从 “和 夺取”,， 只 能 从 Oracle 重 新 加 载 ， 才 能 获取 此 两 行 记录 的 独占 权 。 


@ 在 ttalex01 上 执行 : 


Command> call ttGridDetach; 

Command> call ttGridNodeStatus; 

< MYGRID, 3, 1, T, myactive02, MYGRID ttalex02 3, .> 
Command> select * from alex.tt gawt 602; 

0 rows found. - 


@ 在 ttalex02 上 执行 : 


Command> select * from alex.tt gawt 602; 

< A 入 

1 row found. 

Command> select * from alex.tt gawt 602 where id=27 
0 rows found. a 

Command> select * from alex.tt gawt 602 where igd=3; 
0 rows found. 

Command> load cache group cacheuser.cg gawt 602 commit every 0 rows; 
2 cache instances affected. 

Command> select * from alex.tt gawt 602; 

<1, aaa> 

< 2, bbb > 

* 3 GE 包 

3 rows found. 


如 果 在 缓存 网 格 中 使 用 普通 的 全 局 AWT 绥 存 集合 的 话 ， 如 果 丢 失 一 个 节点 ， 那 么 该 节点 上 独占 的 数据 将 需要 重新 从 Oracle 加 载 到 
cg_gawt_602 是 动态 的 全 局 缓存 集合 就 不 会 有 这 个 问题 了 。 


他 节点 ， 否 则 在 网 格 中 就 丢失 数据 了 。 然 而 ， 如 果 缓 存 集合 


将 cg_gawt_602 重 建 为 动态 的 全 局 缓存 集合 ，ID=2 和 ID=3 的 行 被 ttalex01 节 点 独占 ，ID=1 的 行 被 ttalex02 独 占 ， 当 ttalex01 被 剔除 后 ， 于 ttalex02 节 点 进行 ID=2 和 ID=3 的 主键 等 值 查询 ， 因 为 
cg_gawt 602 为 动态 全 局 缓存 集合 ， 当 无 法 从 ttalex01“ 和 夺取 ”独占 权时 ， 会 自动 从 Oracle 中 加 载 。 如 下 示例 所 示 : 


@ 在 两 个 节点 重建 动态 缓存 集合 : 


Command> create dynamic asynchronous writethrough global cache group 
> cacheuser.cg gawt 602 
> from alex.tt gawt 602 (id number primary key, 
> name Varchar2 (100)); 


@ 在 ttalex01 上 查询 : 


Command> select * from alex.tt gawt 602; 
过 忆 

过. 3 从 记 

2 rows found. 


@ 在 ttalex02 上 查询 : 


Command> select * from alex.tt gawt 602; 
芝 了 入 六 
1 row found. 


@ 在 ttalex01 上 执行 : 


Command> call ttGridDetach; 

Command> call ttGrigdNodeStatus; 

< MYGRID, 3, 1, T, myactive02, MYGRID ttalex02 3, ... > 
Command> select * from alex.tt gawt 603; 

0 rows found. 加 


@ 在 ttalex02 上 执行 : 


Command> select * from alex.tt gawt 603 where id=2; 
六 全 攻关 加 a 

1 row found. 

Command> select * from alex.tt gawt 603 where igd=3; 
< 

1 row found. 

Command> select * from alex.tt gawt 603; 


区 
3 rows found. 


从 上 述 示例 可 见 ， 在 缓存 网 格 中 使 用 动态 全 局 AWT 缓 存 集合 是 有 必要 的 ， 可 以 降低 由 于 节点 丢失 而 带 来 的 数据 迁移 的 运 维 成 本 。 


6.5.3 ASP 网 格 双 活 架构 


缓存 网 格 的 双 活 架构 本 质 上 来 说， 只 是 提供 了 一 种 比较 灵活 的 负载 均衡 功能 ， 但 是 对 数据 或 节点 的 丢失 并 没有 进行 很 好 的 保护 ， 这 对 要 求 数据 安全 和 一 致 性 比较 高 的 应 用 是 不 够 理想 的 。 然 而 ， 我 们 前 
面 说 到 的 AsP 复 制 架构 却 是 可 以 做 到 的 ， 能 和 否 将 两 者 结合 在 一 起 使 用 呢 ? 当然 可 以 ，TimesTen 的 一 个 优势 就 是 足够 灵活 。 


如 图 6-13 所 示 ， 这 是 一 个 ASP 组 合 节点 和 单 节 点 混合 在 同一 个 缓存 网 格 的 架构 。 通 常 来 说， 缓存 网 格 更 像 是 一 个 容器 ， 可 以 用 来 装载 独立 节点 和 ASP 组 合 节点 ， 在 默认 情况 下 ， 这 些 节点 之 间 是 可 以 没 
有 什么 联系 的 ， 相 互 间 独立 存在 。 然 而 ， 当 创建 了 全 局 AWT 缓 存 集合 之 后 ， 各 节点 就 建立 了 一 种 联系 ， 全 局 缓存 集合 在 各 个 相关 节点 间 实 现 了 数据 的 共享 ， 但 各 节点 还 是 可 以 同时 保留 私有 的 缓存 集合 。 面 
对 过 于 灵活 的 架构 ， 我 们 往往 会 不 知道 如 何 去 选 择 了 。 还 是 秉承 “大 道 至 简 ” 的 观点 : 


:如果 只 是 想 实现 负载 均衡 ， 而 不 考虑 数据 的 高 可 用 性 ， 只 需要 建立 普通 全 局 AWT 缓 存 集合 的 单 节点 的 缓存 网 格 即 可 ; 


“ 如果 要 实现 负载 均衡 的 同时 ， 不 考虑 数据 的 高 可 用 性 ， 只 考虑 能 快速 恢复 ， 则 建立 动态 全 局 AWT 缓 存 集合 的 单 节点 的 缓存 网 格 ; 


:如果 要 是 想 负载 均衡 的 同时 ， 实 现 数据 的 高 可 用 性 ， 则 需要 建立 多 个 ASP 组 合 节点 的 缓存 网 格 。 


tt awt 601 


图 6-13 ASP 网 格 架 构图 


需要 创建 AsP 的 缓存 网 格 也 非常 简单 ， 具 体 步骤 如 下 展开 : 
步骤 1 创建 待 加 入 缓存 网 格 的 ASP， 需 要 加 入 几 组 就 预先 建立 几 组 ， 这 里 我 们 还 是 建立 一 组 (ttalex 和 tsalex) 为 例 。 


@ttalex 执 行 : 


Command> call ttrepstateget; 
< ACTIVE, NO GRID > 


@tsalex 执 行 : 


Command> call ttrepstateget; 
< STANDBY, NO GRID > 


步骤 2 分 别 在 ttalex 和 tsalex 创 建 全 局 的 AWT 缓 存 集合 cg_gawt_602， 示 例如 下 : 


Command> call ttRepStop; 

Command> create asynchronous writethrough global cache group 
> cacheuser.cg gawt 602 
> from alex.tt gawt 602 (id number primary key, 
> name varchar2 (100)); 

Command> call ttRepStart; 


步骤 3 调用 内 置 存 储 过 程 ttGridAttach， 分 别 将 ttalex 和 tsalex 节 点 以 ASP 的 方式 加 入 到 缓存 网 格 中 ， 则 AsP 的 缓存 网 格 即 建立 成 功 ， 可 以 调 有 


@ttalex 执 行 : 


ttGridNodeStatus 进 行 3 


签证 。 示 例如 下 : 


Command> call ttGridaAttach (1, 'ttalex', 'myactive',53335, 'tsalex', 
> "mystandqby'v53335) 7 


@tsalex 执 行 : 


Command> call ttGridAttach (2, 'ttalex', 'myactive',53335, 'tsalex', 
> 'mystandby',53335); 
Command> call ttGrigdNodeStatus; 
< MYGRID, 1, 1, T, myactive, MYGRID ttalex 1A, 172.10.1.11, 53335, T, 
mystandby, MYGRID tsalex 1B, 172.10.1.12, 53335 > 


内 置 存储 过 程 ttGridNodestatus 输 出 参数 说 明 如 表 6-8 所 示 。 


表 6-8 ”ttGridNodeStatus 说 明 


输出 参数 类 型 说 明 
gridName TT VARCHAR (30) 缓存 网 格 名 称 
nodeID TT INTEGER NOT NULL 缓存 网 格 的 ID 号 
activeNode TT INTEGER NOT NULL Active 节点 识别 号 
nodelAttached CHAR (1) NOT NULL Active 节点 网 格 状 态 标 示 : 
口 T 季 点 已 添加 到 网 格 
DF 季 点 未 添加 
Host1 TT VARCHAR (200) NOT NULL Active 节点 的 主机 名 
memberNamel TT VARCHAR (200) NOT NULL Active 库 的 成 员 识 别名 称 
IPaddr1 TT _ VARCHAR (128) NOT NULL Active 节点 IP 地 址 
port1 TT INTEGER NOT NULL Active 节点 端口 号 
〈 续 ) 
输出 参数 类 型 说 明 
node2Attached CHAR (1) NOT NULL Standby 节点 网 格 状态 标示 : 


口 Tf 一 一 节点 已 添加 到 网 格 
口上 一 一 节点 未 添加 


host2 TT VARCHAR (200) NOT NULL Standby 节点 的 主机 名 
memberName2 TT VARCHAR (200) NOT NULL standby 库 的 成 员 识 别名 称 
IPaddr2 TT VARCHAR (128) NOT NULL Standby 节点 IP 地 址 
port2 TT INTEGER NOT NULL Standby 节点 端口 号 


综合 来 看 ， 缓 存 网 格 的 最 大 功能 是 实现 负载 均衡 ，ASsP 的 最 大 功能 是 实现 数据 的 高 可 用 。 如 果 需 要 同时 实现 两 大 功能 ， 就 需要 建立 ASP 的 缓存 网 格 ， 这 样 架 构 就 会 变 得 很 复杂 。 而 且 通 过 前 面 的 验证 测 
试 可 以 看 到 ， 缓 存 网 格 的 灵活 点 太 多 ， 较 难 控制 ， 高 并 发 数据 库 的 应 用 最 好 不 要 使 用 缓存 网 格 来 实现 负载 均衡 。 当 然 ， 我 们 可 以 选择 现下 比较 流行 的 做 法 一 一 分 库 分 表 ， 一 种 在 中 间 件 层 通过 数据 路 由 来 实 
现 负载 均衡 的 方式 。 


6.6 “分 库 分 表 


所 谓 分 库 分 表 ， 就 是 将 原本 存储 在 一 个 库 的 数据 库 表 ， 按 照 一 定 的 业务 逻辑 打 散 到 多 个 库 和 多 个 表 进 行 存储 ， 应 用 通过 中 间 件 层 部 署 的 数据 路 由 组 件 ， 按 照 业 务 逻 辑 识别 数据 存储 位 置 ， 整 个 过 程 对 应 
是 透明 的 。 


在 TimesTen 内 存 数据 库 中 ， 引 进 分 库 分 表 的 技术 ， 一 方面 可 以 解决 负载 均衡 的 问题 ， 另 一 方面 也 可 以 提高 数据 库 横 向 扩展 的 能 力 。 然 而 ， 实 施 分 库 分 表 需 要 注意 以 下 事宜 : 


“ 分 库 分 表 应 该 是 由 业务 来 驱动 的 ， 首 先 要 明确 业务 是 否 能 够 支持 ， 不 能 为 了 分 库 分 表 而 分 库 分 表 ; 
“ 分 库 分 表意 味 着 数据 分 布 式 存储 ， 遵 照 CAP 理 论 ， 保 证 数据 一 致 性 的 同时 ， 会 牺牲 掉 一 定 的 可 用 性 ; 


“ 实现 数据 路 由 方面 的 技术 是 否 成 熟 ? 数据 路 由 中 间 件 需要 完全 贴切 业务 数据 模型 。 


TimesTen 是 要 求 数据 强 一致 性 的 关系 型 数据 库 ， 我 们 在 设计 中 需要 充分 考虑 保证 数据 一 致 性 和 数据 可 用 性 的 平衡 。 不 论 什 么 情况 下 ， 我 们 都 需要 保证 不 丢失 数据 ， 哪 怕 在 某 一 时 刻 数据 不 一 致 ， 也 能 够 
在 事后 进行 追溯 补偿 ， 因 此 异步 复制 方式 的 ASP 架 构 是 不 可 或 缺 的 ， 这 也 意味 着 在 缓存 集合 方面 ， 我 们 只 能 使 用 只 读 缓存 集合 和 AWT 缓 存 集合 。 


只 读 缓存 集合 和 AWT 缓 存 集合 在 分 库 分 表 的 实现 上 ， 也 是 有 着 差别 的 ， 下 面 我 们 将 有 区 分 地 展开 介绍 。 


6.6.1 ”只 读 缓存 集合 的 分 库 分 表 


只 读 缓存 集合 的 分 库 分 表 实 现 方式 相对 比较 简单 ， 常 用 的 方法 在 6.3.7 节 的 缓存 过 滤器 中 也 有 大 致 的 介绍 ， 可 以 在 缓存 集合 创建 的 时 候 ， 添 加 WHERE 子 句 ， 设 定 过 滤 条 件 。 


如 图 6-14 所 示 ， 为 只 读 缓存 集合 实现 分 库 分 表 的 架构 图 。 本 例 中， 我 们 假定 需要 将 只 读 缓存 集合 相关 表 分 作 两 个 数据 库 。 根 据 业务 逻辑 分 析 ， 比 较 可 行 的 方案 是 将 id 字段 对 数值 “2” 取 
模 ，mod (id，2) =0 的 数据 到 分 库 A，mod (id，2) =1 的 数据 到 分 库 B， 每 一 个 分 库 都 是 一 个 独立 的 数据 库 ， 都 有 独立 的 一 套 ASP 架 构 ， 充 分 保证 数据 库 的 高 可 用 性 。 


应 用 层 
中 间 件 层 


mod(id,2)=0 数据 路 由 mod (id,2)=1 


Standby 开 少 受 市 Standby 


mod (id,2) =0 mod (id,2) =] 


自动 刷新 自动 刷新 
mod (id,2) =0 mod (id,2)=1 


Oracle 应 用 写 操作 
mod(id,2)=0 


mod (id,2)=1 


图 6-14 ”只 读 缓存 集合 分 库 分 表 


数据 库 层 


上 述 架 构 中 ，Oracle 数 据 库 保存 着 全 量 的 数据 ， 支 持 应 用 的 写 操作 。 当 发 生 数 据 变 化 的 时 候 ，Oracle 中 的 数据 按照 mod (id，2) 的 判断 逻辑 ， 被 自动 刷新 到 TimesTen 的 两 个 分 库 的 Active 库 ，Active 
库 对 外 提供 只 读 服 务 的 同时 ， 异 步 复 制 到 各 自 对 应 的 Standby 库 。 


通常 情况 下 ， 应 用 层 通 过 中 间 件 层 即 可 连接 数据 库 读 写 数据 ， 本 例 中 读 操作 将 需要 经 过 一 个 数据 路 由 的 中 间 件 层 组 件 来 进行 判断 和 过 滤 。 中 间 件 层 会 预先 配置 A 和 B 两 个 数据 源 连接 ， 分 别 对 应 分 库 A 的 
Active 库 和 分 库 B 的 Active 库 ， 当 数据 路 由 判断 到 mod (id，2) =0 时 ， 中 间 件 自动 选择 数据 源 连接 A， 连 接 到 分 库 A 的 Active 库 进行 数据 读 取 ， 而 当 mod (id，2) =1 时 ， 则 选择 数据 源 连 接 B。 


以 上 就 实现 了 一 个 比较 简单 的 分 库 分 表 架 构 。 当 任意 分 库 的 Active 节 点 宕 机 ， 会 出 现 短暂 的 数据 不 可 用 ， 需 进行 ASP 的 故障 切换 。 如 果 在 故障 切换 过 程 中 ， 持 续 对 外 提供 服务 ， 因 为 故障 节点 上 的 数据 
在 Oracle 是 可 见 的 ， 写 操作 不 受 影响 ， 但 是 写 完成 后 ， 查 询 不 到 ， 数 据 看 似 “ 丢 失 ” 了 ， 出 现 了 短暂 的 数据 不 一 致 。 但 是 ， 数 据 并 没有 真正 丢失 ， 短 暂 的 不 一 致 ， 我 们 是 可 以 接受 的 (应 用 端 从 写 切换 到 读 
也 是 需要 时 间 的 ， 实 现 快速 切换 的 话 ， 应 用 端 甚至 可 能 感觉 不 到 问题 的 存在 ) ， 因 为 这 似乎 要 比 同时 关闭 故障 节点 对 应 的 读 写 服务 要 影响 更 小 一 些 。 


整体 来 看 ， 上 述 分 库 分 表 的 实现 ， 其 技术 上 的 要 点 就 在 于 ASP 的 快速 故障 切换 和 数据 路 由 控制 ， 两 者 是 缺 一 不 可 的 。 


6.6.2”AWT 缓 存 集合 的 分 库 分 表 


如 果 理解 了 只 读 缓存 集合 分 库 分 表 实 现 的 原理 ，AWT 缓 存 集合 的 实现 也 不 会 太 难 理解 。 同 样 需要 在 Oracle 数 据 库 中 保存 全 量 的 数据 ， 数 据 不 丢失 是 架构 实现 的 基本 保障 。 因 为 缓存 过 滤器 只 能 用 于 只 读 
缓存 集合 ， 所 以 这 里 我 们 不 能 使 用 ， 只 能 通过 数据 路 由 组 件 来 实现 分 库 分 表 的 数据 分 布 存储 了 。AWT 缓 存 集合 分 库 分 表 ， 如 图 6-15 所 示 。 


中 间 件 层 


路 生 
mod(id,2)=0 数据 路 由 mod (id.2) =1 


分 库 B 
Active 
mod(id,2)=1 


异步 复制 


Standb 
andby : 


Standby 


mod (id,2)=1 


mod (id,2)=0 mod(id,2)=0 


动态 加 载 
自动 衍化 mod (id,2)=1 
mod(id,2) =0 


自动 衍化 
mod(id,2)=1 
动态 加 载 
mod(id,2)=0 Oracle 
mod (1d,2) =0 


mod(id,2)=1 


数据 库 层 


图 6-15 AWT 缓 存 集合 分 库 分 表 


在 此 架构 中 ，Oracle 是 不 对 应 用 提供 任何 服务 的 ， 应 用 端的 读 写 操 作 都 是 通过 TimesTen 数 据 库 来 实现 的 。 其 中 ， 最 关键 的 一 点 是 如 何 实现 将 mod (id，2) =0 的 数据 放 到 分 库 A 中 ， 而 将 
mod (id，2) =1 的 数据 放 到 分 库 B 中 。 这 里 ， 我 们 只 有 借助 动态 AWT 缓 存 集合 ， 按 需 加 载 数据 到 TimesTen 分 库 。 而 动态 加 载 有 一 个 先决 条 件 ， 就 是 只 有 按照 主键 等 值 查询 的 时 候 才 能 触发 动态 加 载 。 虽 
然 ， 数 据 路 由 组 件 能 够 将 数据 按照 mod (id，2) 的 逻辑 在 分 库 A 和 分 库 B 中 区 分 存储 和 访问 ， 但 也 不 可 避免 地 需要 对 空 的 动态 AWT 缓 存 集合 进行 初始 化 动态 加 载 ， 也 就 是 说 当 要 读 写 jid=1 的 行 ， 则 先 要 主键 
等 值 查询 一 次 ， 如 果 要 读 写 100 行 ， 则 要 查询 100 次 来 预 加 载 ， 这 是 很 不 方便 的 。 当 然 ， 可 以 在 使 用 之 前 ， 预 先 按照 mod (id，2) 的 逻辑 分 类 加 载 到 各 个 分 库 中 。 


这 种 实现 方式 看 起 来 好 像 很 麻烦 嘛 ， 为 什么 不 直接 使 用 ASP 的 缓存 网 格 架 构 来 实现 呢 ? 两 者 有 什么 区 别 吗 ? 两 者 最 大 的 区 别 在 于 由 谁 来 控制 各 节点 的 数据 一 致 性 。 在 本 例 中 ， 各 个 节点 的 数据 一 致 性 是 
由 数据 路 由 来 实现 的 ， 且 仅 对 应 用 层 实 现 了 访问 时 的 数据 一 致 性 ， 至 于 各 个 节点 数据 库 的 数据 是 否 一 致 ， 数 据 路 由 是 不 加 以 控制 的 ， 也 可 以 说 它 并 不 能 真正 保证 各 数据 库 的 数据 一 致 性 ， 但 是 其 保证 了 数据 
的 访问 效率 。 对 于 ASP 的 缓存 网 格 来 说 ， 其 通过 网 格 服务 在 数据 库 层面 保证 了 各 节点 数据 库 的 数据 一 致 性 ， 而 在 应 用 访问 的 时 候 ， 自 然而 然 就 有 了 数据 的 一 致 性 ， 但 是 网 格 服务 是 有 相对 开销 的 ， 对 访问 效 
率 有 一 定 的 制约 性 。 


综合 来 看 ， 分 库 分 表 也 是 有 利 有 浆 的 ， 对 于 架构 设计 来 说， 不 是 必需 的 ， 当 其 可 以 带 来 应 用 性 能 和 并 发 处 理 能 力 的 提升 ， 可 以 有 选择 性 地 使 用 。 


6.7 TimesTen 设 计 与 管理 


介绍 完了 宏观 的 架构 设计 方面 的 知识 点 ， 下 面 我 们 将 展开 一 些微 观 的 关于 TimesTen 细 节 问 题 的 介绍 。 所 谓 细节 决定 成 败 ， 在 数据 库 管理 方面 的 细节 问题 也 是 不 容 忽视 的 。 


6.7.1” 表 设计 与 管理 


对 于 TimesTen 内 存 数据 库 的 表 的 设计 ， 可 以 分 为 两 个 维度 来 看 : 


' 当 Timesten 作 为 Oracle 的 缓存 数据 库 (In-Memory Database Cache) 使 用 时 ， 其 缓存 集合 中 表 的 字段 类 型 和 长 度 必 须 与 Oracle 中 对 应 表 字 段 类 型 和 长 度 保 持 一 致 ， 同 时 Timesten 的 字符 集 与 Oracle 数 据 库 字 
符 集 应 该 也 保持 一 致 。 


: 当 Timesten 作 为 独立 数据 库 来 使 用 时 ， 创 建 本 地 表 则 尽量 使 用 Timesten 特 有 的 字段 类 型 ， 如 NUMBER 字 段 类 型 可 以 使 用 TT_SMALLINT、TT_INT、TT_TINYINT、TT_BIGINT。 


当 TimesTen 作 为 Oracle 缓 存 数据 库 使 用 时 ， 更 需要 关注 表 设 计 中 的 一 些 细节 : 


“ 表 字 段 不 宜 过 多 ， 且 字段 不 宜 过 长 ，TimesTen 存 储 具有 字段 对 齐 的 特点 ， 通 常情 况 下 比 Oracle 需 要 更 多 的 存储 空间 ， 仅 缓存 必要 字段 即 可 ， 不 需要 的 字段 不 进行 缓存 ; 

“ 当 TimesTen 表 的 字段 长 度 超 过 128 字 节 ， 则 会 启用 行 外 存储 ， 会 影响 到 表 的 性 能 ， 需 要 尽 可 能 地 做 到 “精打细算 ”， 能 少 给 1 个 字 节 ， 坚 决 不 多 给 1 个 ， 这 同时 也 是 出 于 节省 内 存 的 考虑 ; 
“ 单 表 的 容量 尽 可 能 地 控制 到 越 小 越 好 ; 

:TimesTen 中 ， 表 和 索引 均 保 存在 内 存 中 ， 内 存 估算 很 重要 ， 单 库 尽 可 能 控制 在 50 至 60GB ， 不 超过 100GB ， 使 故障 处 理 的 成 本 降低 。 


在 TimesTen 表 的 设计 过 程 中 ， 基 本 上 是 怎么 简单 怎么 来 ， 怎 么 节省 内 存 怎么 来 ， 怎 么 有 利于 性 能 怎么 来 。 


by 


对 于 没有 使 用 过 TimesTen 的 读者 ， 一 下 子 抛 出 这 么 多 概念 性 的 经 验 之 谈 ， 可 能 会 一 头 雾 水 。 下 面 我 们 将 分 三 个 方面 来 介绍 TimesTen 表 的 特别 之 处 。 


1. 特 有 字段 


因为 当 Timesten 作 为 Oracle 的 缓存 数据 库 使 


更 多 情况 下 ，TimesTen 特 有 字段 类 型 是 用 于 本 地 表 中 。 如 下 创建 两 个 测试 
字段 类 型 的 选择 TimesTen 的 数据 类 型 : tt_intintt_varchar。 


@ 兼 容 字 段 类 型 表 : 


时 ， 为 了 保证 更 好 的 兼容 性 ， 需 要 保证 与 Oracle 数 据 库 的 字段 类 型 和 长 度 的 一 致 性 ， 所 以 TimesTen 特 有 的 字段 类 型 就 无 法 发 挥 作 


Ts 


表 ， 分 别 包含 一 个 数值 类 型 字段 和 一 个 字符 类 型 字段 ， 兼 容 字 段 类 型 的 选择 Oracle 的 数据 类 型 : number 和 varchar2， 特 有 


Command> create table alextt.tt tab 601 (id number Primary key, 
> name Varchar2 (100) ) 


@ 特 有 字段 类 型 表 : 


Command> create table alextt.tt tab 602 (id tt int primary key, 
> name tt varchar (100) ) 7 


图 


然后 ， 自 定义 一 个 事务 ， 其 包含 增删 改 查 的 操作 ， 按 照 操作 记录 行 数 的 不 同 进行 分 级 测试 。 如 


6-16 所 示 ， 是 我 测试 结果 的 一 个 图 示 。 从 100 行 记录 、1000 行 记录 、10000 行 记录 、100000 行 记录 几 个 


典型 的 情况 来 看 ， 当 发 生 批 量 事务 操作 的 时 候 ， 选 择 TimesTen 数 据 库 特 有 的 数据 类 型 字段 在 性 能 上 是 有 比较 明显 的 优势 的 。 其 优势 在 于 字段 的 存储 方式 和 寻 址 方式 上 ， 我 们 知道 TimesTen 是 内 存 型 数据 


库 ， 在 内 存 寻 址 上 做 了 很 多 优化 ， 特 有 数据 类 型 字段 的 寻 址 就 是 其 中 一 方面 ， 相 对 于 Oracle 兼 容 的 字段 类 型 | 


有 更 大 的 优势 。 
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图 


而 在 存储 方式 上 ， 特 有 字段 类 型 也 是 作 了 相关 优化 的 ， 它 使 得 存储 相同 量 的 数据 需要 更 少 的 内 存 开销 。 


10 000 100 000 


口 特有 字段 类 型 


兼容 字段 与 特有 字段 性 能 对 比 


ttSize 命 令 分 别 查询 上 述 测试 用 的 兼容 字段 类 型 表 tt_tab_601 和 特有 字段 类 型 表 


如 下 所 示 , 使 


tt tab_602 的 内 存 使 用 情况 。 可 以 看 到 ， 同 样 存 储 100 万 行 相同 的 数据 ， 表 tt_tab_601 消 耗 内 存 约 15.69MB， 而 表 tt_tab_602 仅 消耗 14.16MB， 内 存 节省 近 10%。 


@ 兼 容 字 段 类 型 表 : 


$ ttSize -tbl alextt.tt tab 601 ttalex 

Rows = 100000 

Total in-line row bytes = 16450478 

Indexes: 

Range index ALEXTT.TT TAB 601 adds 2541274 bytes 
Total index bytes = 2541274 

Total = 18991752 


@ 特 有 字段 类 型 表 : 


$ ttSize -tbl alextt.tt tab 602 ttalex 

Rows = 100000 

Total in-line row bytes = 14848942 

Indexes: 

Range index ALEXTT.TT TAB 602 adds 2538970 bytes 
Total index bytes = 2538970 

Total = 17387912 


以 上 分 析 可 得 出 结论 ， 尽 可 能 多 地 使 


2. 字 段 对 齐 


TimesTen 特 有 数据 类 型 字段 ， 不 仅 能 带 来 存储 内 存 的 节约 ， 更 能 带 来 事务 处 理 能 力 的 提升 ， 可 谓 一 举 两 得 。 


我 们 说 到 TimesTen 在 进行 内 存 寻 址 的 方式 上 作 了 相关 的 优化 ， 在 得 到 性 能 优势 的 同时 ， 却 带 来 了 存储 性 能 的 负担 。 


在 Oracle 数 据 库 中 ， 表 是 实际 存储 在 物理 磁盘 上 的 ， 当 表 中 有 一 个 字符 型 字段 “name” 为 “varchar2 (100) ”， 那 么 对 于 变 长 的 字段 来 说 ， 存 储 “abc” 


节 ) 的 磁盘 开销 是 不 一 样 的， 存储 更 短 的 数据 将 更 节省 空间 ， 这 是 变 长 字段 带 来 的 优势 。 


而 在 TimesTen 数 据 库 中 ， 由 于 表 是 实际 存储 在 内 存 中 的 ， 如 果 定 义 字符 型 字段 “name” 为 “varchar2 (100) ”， 那 么 其 存储 “abc”“ 


是 一 样 的 ， 这 一 特点 我 们 称 为 字段 对 齐 ， 其 字段 存储 的 内 存 开销 取决 于 字段 定义 的 长 度 大 小 。 


(3 个 字 节 ) 和 存储 “aaabbbccc” (9 个 字 


(3 个 字 节 ) 和 存储 “aaabbbccc” (9 个 字 节 ) 的 内 存 开销 将 


如 下 例 所 示 ， 表 tt_readonly_601 是 一 个 只 读 缓存 集合 表 ， 包 含 ID 和 NAME 两 个 字段 ， 其 中 NAME 为 VARCHAR2 (100) 。 当 在 Oracle 数 据 库 中 插入 10 万 行 记录 (NAME 字 段 数 据 均 为 6 个 字 节 ) ， 表 


tt_readonly 601 在 Oracle 中 占用 空间 仅 2MB， 而 在 TimesTen 中 占用 了 15.69MB 空 间 。 正 如 前 面 所 述 ， 对 于 没有 充分 利用 的 字段 ， 由 于 字段 对 齐 的 特性 ，TimesTen 造 成 了 很 大 的 存储 空间 浪费 。 


SQL> desc alex.tt readonly 601 
Name Type 
ID NUMBER 
NAME VARCHAR2 (100) 
SOL> begin 
2 for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 100000 loop 
3 insert into alex.tt readonly 601 values (i, 'Oracle'); 
4 end loop; 
5 commit; 


SQL> select bytes from dba _ segments where 

2 segment name='"'TT READONLY 601'; 
BYTES 

2097152 

$ ttSize -tbl alex.tt readonly 601 ttalex 

Rows = 100000 加 本 

Total in-line row bytes = 16450478 

Indexes: 

Range index ALEX.TT READONLY 601 adds 2541274 bytes 
Total index bytes = 2541274 

Total = 18991752 


然而 ， 当 NAME 字 段 存 储 的 是 100 个 字 节 长 的 数据 呢 ，TimesTen 还 会 造成 存储 空间 浪费 吗 ? 如 下 所 示 ， 当 在 Oracle 数 据 库 中 插入 10 万 行 记录 (NAME 字 段 数据 均 为 100 个 字 节 ) 后 ， 表 tt_readonly_601 
在 Oracle 中 占用 空间 增长 到 13MB， 而 在 TimesTen 中 由 于 字段 对 齐 特性 ， 占 用 空间 仍 为 15.69MB。 


SOL> begin 
2 for i in 1 http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/.. 100000 loop 
和 insert into alex.tt readonly 601 values 
4 (I, rpad('Oracle',100,' ')); 
S end loop; 
6 


SQL> select bytes from dba segments where 

2 segment name="'TT READONLY 601'7 
BYTES 加 

13631488 

$ ttSize -tbl alex.tt readonly 601 ttalex 

Rows = 100000 

Total in-line row bytes = 16450478 

Indexes: 

Range index ALEX.TT READONLY 601 adds 2541274 bytes 
Total index bytes = 2541274 

Total = 18991752 


如 此 看 来 ， 存 储 相 同 量 的 数据 ，TimesTenttOracle 需 要 更 多 的 存储 空间 。 由 于 TimesTen 的 字段 对 齐 特性 ， 需 要 合理 化 选择 缓存 字段 数 和 字段 长 度 。 


3. 行 外 存储 


在 TimesTen 数 据 库 中 ， 不 论 是 缓存 表 还 是 本 地 表 ， 当 字段 长 度 超 过 了 128 个 字 节 ， 就 会 出 现行 外 存储 。 所 谓 行 外 存储 就 是 将 字段 长 度 超 过 128 个 字 节 的 字段 从 行内 排除 ， 存 储 在 行 外 的 内 存 区 域 中 ， 并 
在 行内 保存 一 个 指针 指向 该 行 外 内 存 区 域 。TimesTen 为 什么 会 有 这 样 的 设计 呢 ? 主要 有 以 下 两 点 原因 : 


| 


“ 对 于 过 长 的 字段 ， 放 在 行内 进行 存储 ， 会 导致 行 长 剧 增 ， 是 不 利于 性 能 优化 的 ; 
“ 行内 存储 是 有 字段 对 齐 特性 的 ， 而 行 外 存储 是 没有 的 ， 将 过 长 的 字段 进行 行 外 存储 有 利于 存储 空间 的 节省 。 


通过 一 个 例子 来 看 一 下 吧 ， 新 建 两 个 本 地 表 tt_tab_611 和 tt tab 612 (name 字 段 长 200) ， 分 别 插入 1 万 行 name 字 段 长 150 的 记录 和 1 万 行 name 字 段 长 180 的 记录 ， 来 考察 一 下 两 种 情况 下 表 的 内 存 使 
情况 吧 。 


@ 测 试 表 : 


SQL> create table alextt.tt tab 611 (id number primary key, 
2 name varchar2(200)); 

SQL> create table alextt.tt tab 612(id number primary key, 
2 name varchar2(200)); 


@ 循 环 插入 10000 行 记录 : 
SQL> insert into alextt.tt tab 611 values (i, rpad('Oracle',150,' ')); 
SQL> insert into alextt.tt tab 612 values (i, rpad('Oracle',180,' ')); 


查询 结果 如 下 所 示 ， 两 种 情况 的 行内 存储 空间 均 为 629502 个 字 节 ， 其 仅 对 id 字段 数据 和 name 字 段 寻 址 指针 进行 了 存储 ， 而 name 字 段 的 数据 则 是 进行 了 行 外 存储 。 当 插入 记录 的 name 字 段 长 为 150 
时 ， 其 行 外 存储 空间 为 1760000 字 节 ， 而 当 插入 记录 的 name 字 段 长 为 180 时 ， 其 行 外 存储 空间 为 2080000 字 节 ， 由 此 验证 了 行 外 存储 是 没有 字段 对 齐 特性 的 。 


@name 字 段 长 150: 


$ ttSize -tbl alextt.tt tab 611 ttalex 

Rows = 10000 a 

Total in-line row bytes = 629502 

Out-of-line columns : 
Column NAME total 1760000 avg size 176 
Total out-of-line column bytes = 1760000 


@name 字 段 长 180: 


$ ttSize -tbl alextt.tt tab 612 ttalex 

Rows = 10000 

Total in-line row bytes = 629502 

Out-of-line columns: 
Column NAME total 2080000 avg size 208 
Total out-of-line column bytes = 2080000 


np 


虽然 说 TimesTen 与 Oracle 同 是 Oracle 公 司 的 关系 型 数据 库 产品 ， 但 TimesTen 作 为 一 款 内 存 数 据 库 ， 在 表 的 设计 和 管理 上 有 其 独特 之 处 ， 是 需要 与 Oracle 有 所 区 别 的 。 


6.7.2 ”索引 管理 


了 解 了 TimesTen 中 表 的 设计 ， 再 来 讨论 一 下 常用 索引 的 设计 与 管理 吧 。 在 TimesTen 内 存 数 据 库 中 ， 主 要 有 三 种 索引 类 型 : 


“ 范围 索引 (Range Index) : 范围 索引 主要 用 于 指定 列 的 等 值 或 范围 查询 ， 过 滤 出 符合 条 件 的 记录 行 ， 其 可 以 基于 单列 或 者 多 列 来 创建 唯一 键 或 非 唯 一 键 索引 。 同 时 ，NULL 值 是 被 允许 的 ， 但 在 排除 过 
程 中 ，TimesTen 会 视 其 大 于 所 有 非 空 值 。 


“位 图 索引 (Bitmap Index) : 位 图 索引 中 每 一 个 位 对 应 表 中 一 行 ， 主 要 用 于 对 选择 度 比 较 低 的 列 进行 查询 ， 多 用 于 数据 仓库 的 数据 分 析 工 作 ， 虽 然 比 范围 索引 更 节省 空间 ， 但 其 DML 并 发 事务 处 理 能 力 
较 之 更 差 。 


“ 哈 希 索引 (Hash Index) : 哈 希 索引 可 以 给 等 值 查 询 或 等 值 联 立 带 来 性 能 优势 ， 且 每 个 表 上 只 能 创建 一 个 哈 希 索引 。 但 是 ， 哈 希 索 引 将 不 利于 范围 查询 ， 也 不 支持 前 导 列 模糊 查询 ， 由 于 比 范围 索引 和 
位 图 索引 更 加 消耗 存储 空间 ， 其 DML 事 务 处 理 的 成 本 也 更 高 ， 故 在 新 版 的 TimesTen 中 默认 主键 索引 也 由 哈 希 索引 变 为 了 范围 索引 。 


网 


对 比 三 种 索引 来 看 ， 在 处 理 高 并 发 OLTP 应 用 上 ， 位 图 索引 并 没有 什么 使 用 价值 ， 而 哈 希 索引 虽然 能 提高 等 值 查询 的 性 能 ， 但 不 利于 事务 处 理 ， 也 不 及 范围 索引 的 价值 。 因 此 ， 我 们 应 该 更 倾向 于 选择 范 
围 索引 ， 其 与 Oracle 中 最 常用 的 B 树 索引 非常 类 似 。 在 TimesTen 中 ， 有 两 种 较为 常用 的 范围 索引 ， 分 别 为 : T 树 索引 、B 树 索引 。 其 中 ，T 树 索引 是 TimesTen 原 生态 的 索引 。 在 早期 版 本 中 ，TimesTen 不 支 
持 B 树 索引 ， 只 能 使 用 T 树 索引 ， 为 了 与 Oracle 充 分 地 兼容 ， 引 进 了 与 Oracle 相 类 似 的 B 树 索引 ， 并 在 新 版 的 TimesTen 中 作为 默认 索引 类 型 。 


在 一 个 TimesTen 数 据 库 中 ，T 树 索引 和 B 树 索引 是 不 能 共存 的 ， 要 么 整 库 选择 使 用 T 树 索引 ， 要 么 整 库 选 择 使 用 B 树 索引 。 索 引 类 型 的 选择 是 由 初始 化 参数 RangelndexType 来 决定 的 ， 该 参数 设置 后 就 
不 能 被 修改 了 。RangelndexType=0 时 ， 使 用 B 树 索引 ; RangelndexType=1 时 ， 使 用 T 树 索引 。 


T 树 索引 和 B 树 索引 不 能 并 存在 同一 个 数据 库 中 ， 那 我 们 如 何 进行 选择 呢 ， 是 简单 地 选择 新 引进 的 B 树 索引 ， 还 是 墨 守 原生 态 的 T 树 索引 呢 ? 在 回答 这 个 问题 之 前 ， 我 们 有 必要 先 了 解 一 下 两 者 各 自 的 特性 
和 优势 所 在 。 


到 6-17 所 示 为 我 在 模拟 高 并 发 事务 处 理 情况 下 的 测试 结果 。 自 定义 了 一 个 事务 ， 其 包含 INSERT、SELECT、UPDATE 及 DELETE 操 作 ， 随 着 并 发 压力 的 增 大 ，B 树 索引 所 对 应 的 表 ， 不 论 在 读 能 力 还 写 能 
力 上 ， 都 越发 表现 出 优势 。 高 并 发 处 理 能 力 的 提升 ， 也 正 是 使 用 B 树 索引 的 原因 所 在 。 
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图 6-17 了 B 树 索引 与 T 树 索引 事务 吞吐 量 对 比 图 


B 树 索引 带 来 并 发 处 理性 能 提升 的 同时 ， 也 会 带 来 内 存 空间 的 更 多 消耗 。 如 下 例 所 示 ， 在 B 树 索引 和 T 树 索引 所 在 的 数据 库 分 别 创建 两 个 表 tt_tab_621 和 tt_tab_622， 并 分 别 插入 2 万 行 记 录 。 可 以 看 到 ， 
表 的 存储 空间 均 为 3333086 字 节 ， 而 B 树 索引 IDX_TT_ TAB_621 占 用 空间 为 514810 字 节 ，T 树 索引 IDX_TT_TAB_622 占 用 空间 为 409834 字 节 ， 对 于 同样 的 数据 量 和 表 结构 ，B 树 索引 消耗 了 更 多 的 内 存 空间 。 


@ 创 建 结构 相同 的 表 : 


Create table tt tab 621 (id number Primary key, name Varchar2 (100) ) 7 
Create table tt tab 622 (id number Primary key, name Varchar2 (100) ) 7 


@B 树 索引 对 应 数据 库 执行 : 


Command> select t.tblname, i.ixname, i.ixtype, 
(case i.ixtype when 0 then 'HASH' 
when 1 then 'T-TREE' 
when 2 then 'BITMRP' 
when 3 then 'B+TREE' 
else 'WeirdTypeFound' end) 

from tables t, indexes i 

where t.tblowner = current user 

and t.tblid = i.tblid 


Vvvvvvvvyv 


order by t.tblname, i.ixtype; 

< TT TAB 621, IDX TT TAB 621, 3, B+TREE > 

$ ttSize -tbl alextt.tt tab 621 ttalex 

Rows = 20000 Pe 

Total in-line row bytes = 3333086 

Indexes: 

Range index ALEXTT.IDX TT TAB 621 adds 514810 bytes 


@T 树 索引 对 应 数据 库 执行 : 


Command> select t.tblname, i.ixname, i.ixtype, 
(case i.ixtype when 0 then 'HASH' 
when 1 then 'T-TREE' 
when 2 then 'BITMAP' 
when 3 then 'B+TREE' 
else 'WeirdTypeFound' end) 

from tables t, indexes i 

where t.tblowner = current user 


Vvvvvvv 


> and t.tblid = i.tblid 
order by t.tblname, i.ixtype; 
过 了 工 622, IDX TT TAB 622, 1, T-TREE > 
$ ttSize -tbl alextt.tt tab 622 tsalex 
Rows = 20000 
Total in-line row bytes = 3333086 
Indexes: 
Range index ALEXTT.IDX TT TAB 622 adds 409834 bytes 


综合 来 看 ， 能 够 赢得 并 发 处 理 能 力 的 提升 ， 牺 牲 一些 内 存 空间 也 是 值得 的 ， 因 为 使 用 TimesTen 内 存 数据 库 的 初衷 也 是 为 了 提升 OLTP 系 统 的 并 发 处 理 能 力 。 当 我 们 在 设计 一 个 并 发 要 求 很 高 的 数据 库 系 
统 的 时 候 ， 不 妨 直接 使 用 TimesTen 默 认 提供 的 B 树 索引 方式 。 


细心 的 读者 可 能 会 问 到 一 个 问题 : “Oracle 索 引 设计 (参见 2.4.1 节 ) 中 介绍 过 ， 在 Oracle 数 据 库 中 ，B 树 索引 出 现 并 发 事务 会 产生 5-5 分 裂 ， 以 保证 其 并 发 处 理 能 力 ， 同 时 引起 索引 空间 利用 率 的 大 幅 下 
降 ， 在 TimesTen 中 是 否 也 会 如 此 呢 ? ”我 们 通过 下 面 一 个 例子 来 验证 一 下 吧 。 


创建 两 个 与 表 tt_tab_621 结 构 一 致 的 表 tt_tab 623 和 tt_ tab 624， 并 创建 相应 的 B 树 索引 。 对 表 tt_ tab_623 开 启 500 路 并 发 会 话 ， 每 个 会 话 循环 100 次 插入 操作 ， 而 对 表 tt_tab_623 仅 进行 单线 程 5 万 次 的 
插入 操作 。 其 操作 后 ， 两 个 表 上 的 B 树 索引 大 小 均 为 1019114 字 节 ， 并 没有 因为 并 发 操作 多 而 发 生 索引 结构 的 “膨胀 ”。 验 证 结果 如 下 所 示 : 


$ ttSize -tbl alextt.tt tab 623 tsalex 

Rows = 50000 

Total in-line row bytes = 8248958 

Indexes: 
Range index ALEXTT.IDX TT TAB 623 adds 1019114 bytes 
Total index bytes = 1019114 

Total = 9268072 

$ ttSize -tbl alextt.tt tab 624 tsalex 

Rows = 50000 

Total in-line row bytes = 8248958 

Indexes: 
Range index ALEXTT.IDX TT TAB 624 adds 1019114 bytes 
Total index bytes = 1019114 

Total = 9268072 


同样 ， 当 发 生 数 值 乱 序 插入 的 时 候 ，Oracle 发 生 5-5 分 裂 ， 而 在 TimesTen 上 也 是 不 会 的 。 在 TimesTen 内 存 数 据 库 中 ， 索 引 是 只 存在 于 内 存 结构 中 的 ， 每 次 实例 重新 加 载 的 时 候 ， 就 意味 着 索引 的 重建 。 
这 样 ， 索 引 的 维护 和 使 用 就 不 存在 MO 的 问题 ， 就 不 会 出 现 像 Oracle 一 样 的 索引 热 块 争 用 的 问题 ， 自 然 就 没有 必要 像 Oracle 一 样 将 索引 分 裂 细 化 得 那么 深入 。 从 另 一 个 方面 来 说 ，Oracle 上 索引 的 高 并 发 问 
题 ， 如 果 使 用 TimesTen 的 话 ， 一 定 程度 就 天 然 优 化 了 。 


6.7.3 ”统计 信息 与 执行 计划 


“麻雀 虽 小 ， 五 脏 俱全 。” 在 TimesTen 内 存 数 据 库 中 ， 同 样 是 有 着 查询 优化 器 的 ， 虽 然 不 如 Oracle 的 优化 器 那样 强大 ， 但 是 配置 不 好 ， 同 样 是 会 造成 非常 严重 的 性 能 问题 的 。 因 此 ， 我 们 在 使 
TimesTen 的 时 候 ， 也 需要 更 多 地 关注 它 的 统计 信息 和 执行 计划 等 问题 。 


1. 统 计 信息 管理 


先 来 看 一 下 TimesTen 中 的 统计 信息 管理 吧 。 在 TimesTen 中 有 两 个 系统 表 tbl_stats 和 col_stats， 是 专门 用 来 存储 统计 信息 的 ， 其 结构 如 下 所 示 : 


Command> desc tbl stats; 
System table SYS.TBL STATS: 


Columns : 
TBLID TT BIGINT NOT NULL 
SYS1 TT_BIGINT NOT NULL 
NUMTUPS TT BIGINT NOT NULL 
LASTSTATSUPDATE TT_CHAR (25) 


Command> desc col stats; 
System table SYS.COL STATS: 


Columns : 
TBLID TT BIGINT NOT NULL 
COLNUM TT_SMALLINT NOT NULL 
SYS1 TT BIGINT NOT NULL 
INFO VARBINARY (4194304) NOT INLINE NOT NULL 


接 下 来 ， 我 们 通过 一 个 实例 来 展示 一 下 如 何 对 TimesTen 进 行 统计 信息 收集 管理 。 


步骤 1 创建 一 个 测试 表 tt_tab_631， 并 初始 化 插入 1 万 行 记录 ， 如 下 所 示 : 


Command> create table tt tab 631 (id number primary key, 
> name Varchar2 (100) ) 
Command> begin 
> for i in lhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/..10000 loop 
> insert into tt tab 631 values (i,'TimesTen'); 
> end loop; 
> commit; 
> end; 
>/ 


步骤 2 ”对 测试 表 进 行 全 量 统计 信息 收集 ， 如 下 所 示 : 


Command> call ttOptUpdateStats ('ALEXTT.TT TAB 631', 1, 0); 


内 置 存储 过 程 ttOptUpdateStats 输 出 参数 说 明 如 表 6-9 所 示 。 


表 6-9 ”ttOptUpdateStats 输 出 参数 说 明 


输出 参数 类 型 说 明 


tblName TT_CHAR (61) 表 名 ， 可 以 附带 属 主 名 ， 如 : ALEXTT.TT_TAB_631 
NULL 值 则 表示 当前 A 
invalidate TT INTEGER mm - 程 中 是 否 对 其 他 名 称 排 他 


不 排他 (默认 值 ) 

2 

option TT_INTEGER 是 否 收集 完整 的 关联 统计 信息 

口 NULL 或 0 一 一 收集 完整 关联 统计 信息 (默认 值 ) 
口 1 一 一 仅 收 集 单 体 的 统计 信息 


如 果 表 比较 大 ， 且 收集 操作 的 时 间 窗口 有 限 ， 可 以 使 用 内 置 存 储 过 程 ttOptEstimateStats 来 按 比例 采样 收集 。 下 面 示例 表示 按 203% 的 比例 来 进行 收集 ， 如 下 所 示 : 


Command> call ttOPtEstimateStats ('ALEXTT.TT TAB 631', 1, 
> 120 PERCENT'); 


内 置 存 储 过 程 ttOptEstimateStats 输 出 参数 说 明 如 表 6-10 所 示 。 


表 6-10 ”ttOptEstimateStats 说 明 


输出 参数 类 型 说 。 明 


tblName TT_ CHAR (61) 表 名 ， 可 以 附带 属 主 名 
NULL 值 则 表示 当前 用 户 下 所 有 表 
invalidate TT_ INTEGER Co 是 否 对 其 他 名 称 排他 
不 排他 (默认 值 ) 
a a 
samplestr TT VARCHAR 收集 选项 字符 串 
(255) NOT NULL 口 按 行 收集 一 一 'n ROWS ' ，D 为 行 数 ， 为 大 于 0 的 整数 
口 按 比 例 收集 一 一 'P PERCENT'，P 为 比例 ， 区 间 从 0.0 到 
100.0 


步骤 3 ”对 于 已 经 完成 统计 信息 收集 的 表 ， 有 两 种 方式 可 以 查看 其 统计 信息 ， 一 种 是 调用 内 存 存储 过 程 ttOptGetColStats 进 行 查询 ,可 以 看 到 各 个 列 的 统计 信息 情况 ， 包 括 各 个 列 值 的 数据 分 布 情况 。 
如 下 所 示 : 


Command> call ttOptGetColStats ('ALEXTT.TT TAB 6317)7 
< TT TAB 631, ID, (20, 0, 10000, 10000, (500, 500, 1 ,1, 501, 2), .> 
< TT TAB 631, NAME, (1, 0, 1, 10000, (1, 10000, 0, 'TimesTen', ... > 


另 一 种 方法 是 直接 查询 存储 统计 信息 的 系统 表 tbl_stats 和 col_stats， 如 下 所 示 : 


Command> select * from tbl stats 

> where tblid in 

> (select tblid from tables where tblname='TT TAB 631°'); 
< 1798064, 0, 10000, Mon May 25 16:06:37 2014 > 
Command> select * from col stats 

> where tblid in 

> (select tblid from tables where tblname='TT TAB 631°'); 
< 1798064, 1, 0, 14000000010000000000000000000000102700..... > 
< 1798064, 2, 0, 01000000000000000000000000000000010000..... > 


步骤 4 再 来 看 一 下 在 TimesTen 中 如 何 进行 统计 信息 的 备份 和 恢复 吧 。 前 面 说 到 ，TimesTen 中 的 统计 信息 全 部 保存 在 系统 表 tbl_stats 和 col_stats 中 ， 我 们 可 以 直接 对 这 两 个 表 进行 备 份 ， 也 可 以 使 用 内 
置 存储 过 程 ttOptStatsExport 进 行 备份 。 示 例如 下 : 


Command> call ttOptStatsExport ('ALEXTT.TT TAB 631°'); 

< call ttoptsetcolIntvlstats ('ALEXTT.TT TAB 631', 'ID' Pe PO ye 
< call ttoptsetcolIntvlstats ('ALEXTT. TT TAB 631', 'NAME', 0, (1, .> 
< call ttoptsettblstats ('ALEXTT.TT TAB 631', 10000, | 


与 Oracle 不 同 ， 导 出 的 统计 信息 并 不 会 保存 在 备份 表 中 ， 而 是 通过 查询 结果 输出 备份 脚本 ， 我 们 可 以 通过 这 些 脚本 将 备份 的 统计 信息 重新 写 回 到 TimesTen 中 。 


上 述 脚本 中 包含 的 两 个 内 存 存 储 过 程 : 
“ ttoptsettblstats: 用 于 导入 表 的 统计 信息 ; 


“ ttOptSetColIntvlStats: 用 于 导入 列 的 统计 信息 。 


对 于 有 偏差 的 统计 信息 可 以 调用 内 置 存储 过 程 ttOptClearStats 进 行 清除 ， 并 使 用 备份 脚本 进行 统计 信息 的 恢复 。 


2 执行 计划 控制 


有 统计 信息 就 有 执行 计划 ， 在 TimesTen 中 ， 准 确 的 统计 信息 也 是 为 优化 的 执行 计划 服务 的 。 以 下 面 的 一 个 查询 来 看 ， 当 对 表 TT_TAB_631 进 行 id=105 的 筛选 查询 时 ， 通 过 执行 计划 可 以 看 到 ， 查 询 通过 
索引 IDX_TT_TAB_631 进 行 了 RowLkRangeScan 方 式 的 扫描 。 


@ 打 开 执 行 计划 显 示 功 能 : 


Command> set autocommit 0 
Command> set showplan 1 


@ 查 看 执行 计划 : 


Command> select * from tt tab 631 where iqd=105; 
Query Optimizer Plan: 


STEP: 

LEVEL: 

OPERATION: RowLkRangeScan 
TBLNAME : TT_TAB 631 

IXNAME: IDX TT TAB 631 
INDEXED CONDITION: TT TAB 631.ID = 105 
NOT INDEXED: <NULL> 


< 105, TimesTen > 


在 Timesten 数 据 库 中 ， 可 以 设置 一 些 简单 的 执行 计划 的 干预 ， 比 如 是 否 使 用 索引 、 表 连接 的 顺序 等 。 对 于 上 述 查 询 ， 如 果 我 们 不 希望 使 用 索引 扫描 ， 则 可 以 调用 存储 过 程 ttOptUselndex， 来 提示 
TimesTen 无 视 索 引 IDX_TT_ TAB_631， 直 接 走 全 表 扫 描 。 反 之 ， 也 可 以 强制 SQL 语句 走 被 无 视 了 的 索引 。 


Command> call ttOptUseIndex('IDX TT TAB 631, TT TAB 631, 0'); 
Command> select * from tt tab 631 where id=105; 
Query Optimizer Plan: | 

STEP: 1 

LEVEL: 1 


OPERATION: TblLkSerialScan 
TBLNAME: TT TAB 631 
IXNAME: <NULL> 
INDEXED CONDITION: <NULL> 


NOT INDEXED: TT_TAB 631.ID = 105 
< 105, TimesTen > 


内 置 存储 过 程 ttOptUselndex 输 出 参数 说 明 如 表 6-11 所 示 。 


表 6-11 ttOptUseIndex 说 明 


输出 参数 说 明 


IndexName 索引 名 称 ， 可 带 属 主 名 
CorrelationName 对 应 表 名 ， 可 带 属 主 名 


0 1 1 是 否 强 制 使 用 索引 
Do 强制 无 视 对 应 索引 


加 1 强制 使 用 对 应 索引 


TimesTen 的 优化 器 不 如 Oracle 的 CBO 优 化 器 那样 强大 ， 在 处 理 多 表 联 立 的 时 候 ， 有 可 能 会 造成 联 立 顺序 的 偏差 。 虽 然 我 们 推荐 尽 可 能 少 地 在 TimesTen 的 SQL 语句 中 进行 表 的 关联 ， 但 个 别 时 候 却 也 是 


难以 避免 的 。 此 时 ， 我 们 可 以 借助 内 置 存储 过 程 ttOptsetOrder 来 进行 表 联 立 顺序 的 干预 。 如 果 说 现在 有 三 个 表 (A，B，C) 需要 做 关联 ， 比 较 理想 的 关联 顺序 是 (B，A，C) ， 而 实际 执行 计划 中 的 关联 
顺序 却 是 (C，B，A) ， 那 么 就 可 以 使 用 如 下 方式 强制 SQL 走 较 理 想 的 顺序 : 


Command> call ttOptSetOrder('B A C') 


从 上 述 来 看 ， 不 论 是 设置 表 的 联 立 顺序 ， 还 是 设置 是 否 进 行 索引 扫描 ， 都 与 Oracle 中 的 OUTLINE 非 常 类 似 ， 原 理 上 都 是 给 SQL 语句 添加 HINT 关 键 字 ， 来 干预 执行 计划 。 在 TimesTen 中 ， 这 些 HINT 关 键 
字 被 称 为 旗 标 (Flag) ， 可 以 对 其 进行 设置 ， 以 改变 效率 较 差 的 执行 计划 。 这 些 旗 标 汇总 和 说 明 如 表 6-12 所 示 ， 其 值 为 “1” 则 启用 ， 为 “0” 则 禁用 。 


表 6-12 ” 旗 标 说 明 


旗 标 


BranchAndBound 


DynamicLoadEnable 


DynamicLoadErrorMode 


说 明 
是 否 启 用 执行 计划 的 成 本 分 析 
是 否 启 用 从 Cracle 动态 加 载 缓存 集合 ， 默 认为 启用 
是 否 启用 动态 加 载 错误 模式 ， 默 认为 禁用 


FirstRow 是 否 在 SELECT、UPDATE、DELETE 操作 中 启用 FIRSTROW 优化 
ForceCompile 是 否 启用 执行 计划 的 强制 重 编译 ， 默 认为 禁用 

GenPlan 是 否 启用 PLAN 表 进 行 执行 计划 分 析 

GlobalProcessing 缓存 网 格 中 的 操作 是 否 全 局 执行 ， 默 认 值 为 “0” 


GlobalLocalJoin 


口 0 一 SELECT、UNLOAD 均 在 本 地 执行 

口 1 一 SELECT、UNLOAD 全 局 执行 

缓存 网 格 中 的 JOIN 操作 是 否 全 局 执行 ， 默 认 值 为 “0” 
口 0 一 SELECT、UNLOAD 与 JOIN 均 在 本 地 执行 

口 1 一 SELECT、UNLOAD 全 局 执行 ，JOIN 在 本 地 执行 


Hash 是 否 启用 在 索引 扫描 中 使 用 哈 希 索引 ， 默 认为 启用 

HashGb 是 否 启 用 哈 希 集合 

IndexedOR 是 否 启用 全 表 扫 描 ， 禁 用 则 在 IN 操作 中 使 用 全 表 扫 描 ， 启 用 则 在 OR 
操作 中 使 用 多 个 索引 扫描 

MergeJoin 是 否 启 用 合并 联 立 

NestedLoop 是 否 启 用 NestedLoop 

NoRemRowIdOpt 是 否 局 用 ROWID 内 部 生成 器 ， 如 果 局 用 则 ROWID 不 会 作为 优化 目的 
而 内 部 生成 ， 禁 用 则 可 能 内 部 生成 

PassThrough 参见 表 6-4 

Range 是 否 启 用 在 索引 扫描 中 使 用 范围 索引 ， 默 认为 启用 

Rowia 是 否 启 用 ROWID 

RowLock 是 否 启用 行 级 锁 ， 默认 为 启用 

Scan 引用 全 表 扫 描 

ShowJoinorder 显示 表 的 联 立 顺 序 

TblLock 是 否 启用 表 级 锁 

TmpHash 是 否 启 用 临时 哈 希 扫描 

TmpRange 是 否 启用 临时 范围 扫描 

TmpTable 是 否 启 用 临时 表 


是 否 启用 模糊 查询 的 优化 


UseBoyerMooreStringSearch 


旗 标的 状态 可 以 如 下 调用 进行 查询 : 


Command> call ttOptGetFlag; 


旗 标的 设置 则 可 以 调用 内 置 存 储 过 程 ttOptSetFlag 进 行 配 置 。 如 下 例 所 示 ， 为 开启 进行 强制 MergeJoin 操 作 的 设置 。 


Command> call ttOptSetFlag('MergeJoin', 1); 


在 TimesTen 数 据 库 中 ， 要 求 SQL 语 句 的 执行 时 间 足 够 短 ， 并 发 度 支持 足够 高 ， 可 其 查询 优化 器 又 不 如 Oracle 数 据 库 一 样 好 ， 在 日 常 应 用 中 ， 就 更 应 该 多 多 关注 统计 信息 的 准确 和 执行 计划 的 效率 ， 保 证 
及 时 有 效 地 干预 。 


6.8 TimesTen 性 能 监控 


数据 库 运 行 状态 和 性 能 健康 状态 的 监控 工作 ， 对 于 任何 数据 库 来 说 都 是 必须 要 做 好 的 ，TimesTen 数 据 库 同样 也 不 例外 ， 甚 至 可 以 说 ， 需 要 比 Oracle 投 入 更 多 的 关注 ， 因 为 其 功能 和 强壮 程度 都 远 不 及 
Oracle 数 据 库 。 及 时 发 现 潜在 的 风险 ， 对 于 问题 解决 和 性 能 优化 都 是 有 深刻 意义 的 ， 本 节 将 从 几 个 维度 展开 介绍 TimesTen 如 何 有 效 地 进行 监控 。 


6.8.1 关键 指标 


TimesTen 数 据 库 运 行 过 程 中 ， 系 统 会 自动 收集 大 量 的 统计 数据 ， 并 存放 在 系统 性 能 监控 表 中 。 我 们 可 以 通过 对 这 些 表 和 性 能 指标 数据 的 定时 查询 (直接 写 SQL 进 行 查询 或 者 调用 TimesTen 内 置 存 储 过 
程 进 行 查询 ) ， 来 达到 性 能 监控 的 目的 。 如 果 想 要 自 定义 或 自 开 发 一 些 监控 工具 ， 也 是 离 不 开 这 些 重要 的 系统 表 和 关键 性 能 指标 的 。 主 要 包括 以 下 几 个 方面 : 


1) 系统 监控 统计 数据 表 SYS.SYSTEMSTATS， 其 包含 数据 库 运行 的 性 能 状态 和 系统 统计 数据 等 信息 ， 可 以 直接 查询 获取 监控 数据 。 


2) 系统 监控 表 SYS.MONITOR， 包 含 数据 库 空间 使 用 统计 数据 、 数 据 库 连接 数 、 检 查 点 信息 、 锁 超时 、 事 务 提交 和 回 退 等 信息 。 可 以 直接 查询 该 系统 表 获 取 监 控 数据 ， 也 可 以 在 ttlsql 中 使 用 monitor 
命令 查询 获取 ， 示 例如 下 : 


$ ttIsqgl ttalex 
Command> monitor; 


TIME OF 1ST CONNECT: Fri May 25 15:38:56 2014 
DS_CONNECTS: 9355 

DS_DISCONNECTS: 8575 

DS_CHECKPOINTS: 564 

DS_CHECKPOINTS FUZZY: 564 

DS_COMPACTS: 0 

TYPE MODE: 0 


3) 数据 库 在 交易 量 高 峰 时 期 ， 密 切 关注 


可 能 导致 日 志 堆 积 : 


“ 长 时 间 运 行 的 事务 未 能 及 时 提交 


“ 检查 点 时 间 间 隔 设置 不 当 ， 同 时 也 可 能 导致 磁盘 IO 堵塞; 


“ 复制 压力 过 大 ， 网 络 I/O 压 力 过 大 ; 


“ 事务 锁 未 能 及 时 释放 ; 


“ 数据库 备 份 的 影响 。 


务 日 志 堆 积 情况 ， 特 别 是 在 主 备 复制 的 情况 下 ， 如 果 发 生日 志 堆 积 ， 由 于 担心 主 备 的 数据 差别 太 大 而 不 敢 切 换 ， 这 个 时 候 主 备 将 变 得 不 可 用 。 如 下 几 种 原因 均 


为 了 防止 这 些 情况 的 出 现 ， 叶 致 数据 库 性 能 下 降 。 可 以 使 用 内 置 存储 过 程 ttLogHolds 和 ttCkptHistory 定 期 监控 日 志 的 堆积 情况 。 


Command> call ttLogHolds; 
< 52, 56402184, Replication, myactive: ORACLE:1 > 
< 52, 56408328, Replication, myactive: ORACLE:0 > 


< 58, 49053696, Checkpoint, ttalex.ds0 > 
< 58, 49057792, Checkpoint, ttalex.dsl > 
Command> vertical 1; 

Command> call ttCkptHistory; 


STARTTIME: 2014-04-27 15:18:51.950711 
ENDTIME : 2014-04-27 15:18:52.263591 
TYPE: Fuzzy 
STATUS: Completed 
INITIATOR: Checkpointer 

6.8.2 SQL 监控 


与 Oracle 一 样 ，TimesTen 也 能 够 快速 、 简 单 、 高 效 地 度量 SQL 操 作 的 执行 情况 ， 以 帮助 确定 哪些 SQL 语 句 执行 得 好 ， 哪 些 执行 得 差 。 为 了 减少 开销 ， 最 大 限度 地 提高 查询 性 能 ，TimesTen 提 供 了 很 多 


内 置 存储 过 程 ， 我 们 可 以 通过 调 


“ ttStatsConfig: 控制 采样 配置 参数 的 统计 ; 


来 细 粒 度 评估 SQL 语 句 的 性 能 。 最 为 常用 的 内 置 存 储 过 程 有 以 下 几 个 : 


“ ttSQLExecutionTimeHistogram: 显示 单条 或 多 条 SQL 语句 的 执行 时 间 直 方 图 信息 ; 


“ ttsqlcmdcacheinfo: 返回 TimesTen 的 SQL 缓存 中 所 有 已 编译 SQL 语句 的 执行 情况 ; 


"ttsqlcmdcacheinfo2 : 对 ttsqlcmdcacheinfo 功 能 的 扩展 ; 


“ ttOptCmdCacheInvalidate: 使 表 上 相关 的 SQL 失效 或 者 令 其 需要 重新 编译 ; 


' ttSQLCmdQueryPlan: 查看 某 个 命令 ID (相当 于 Oracle 中 的 SQL ID) 的 执行 计划 。 


通常 来 说 ， 我 们 评估 一 条 SQL 语句 是 否 具有 较 高 的 执行 效率 ， 都 会 从 执行 时 间 、 执 行 次 数 、 平 均 执行 时 间 来 考察 ， 进 而 分 析 SQL 语 句 的 执行 计划 。 那 么 如 何 来 定位 有 问题 的 连接 会 话 和 SQL 语句 呢 ? 如果 


有 Oracle 的 经 验 ， 定 位 和 分 析 就 不 难 了 ， 下 面 通过 一 个 分 析 示 例 来 展示 一 下 吧 。 


首先 需要 找到 问题 会 话 的 PID 和 问题 事务 的 TransID， 这 个 可 以 通过 ttXactAdmin 命 令 来 查询 。 该 命令 的 使 用 帮助 信息 可 以 通过 执行 “ttXactAdmin-help” 来 获取 。 下 例 中 ， 可 以 看 到 两 个 用 户 


步骤 1 


级 的 会 话 连接 ， 其 中 PID=13896 的 会 话 在 事务 (TransID=5.94) 执行 中 ， 该 会 话 就 是 我 们 需要 分 析 的 会 话 (通常 情况 下 ， 可 以 借助 0S 的 top 命 令 来 帮助 定位 问题 会 话 ) 。 


$ ttXactAdmin -connstr "dsn=ttalex" -connections 


ID PID Context Name Program State TransID UID 

5 13896 0x0000000001c44480 ttalex ttIsqlCmd Run 5.94 RLEXTT 

8 11103 0x0000000002940480 ttalex ttIsqlCmd Run ALEXTT 

步骤 2 ”明确 了 问题 会 话 ， 可 以 用 ttXactAdmin 命 令 进一步 明细 查询 。 如 下 例 所 示 ， 可 以 直接 通过 会 话 号 查询 ， 也 可 以 通过 事务 号 来 查询 。 此 时 ， 我 们 明确 了 事务 关联 对 象 和 对 应 SQL 语 句 的 ID 号 


(SqlCmdlID) ， 也 正 是 前 面 所 说 的 命令 1D。 


@ 通 过 会 话 号 查询 : 


$ ttXactAdmin -connstr "dsn=ttalex" -pid 13896 


@ 通 过 


有 务 号 查询 : 


$ ttXactAdmin -connstr "dsn=ttalex" -xact 5.94 


@ 查 询 结果 : 
PID TransID Resource ResourceID Mode SqlCmdID 
13896 5.94 Database 0x0131290001312d00 IX 


Row BMUFVUAAACdAAAACD6 Un 362104416 
Table 1798064 IUn 362104416 


Name 


ALEXTT. TT_ TAB 631 
ALEXTT .TT_ TAB_631 


步骤 3 有 了 命令 1D 就 可 以 进入 分 析 的 正题 了 ， 回 到 TimesTen 的 ttlsql 环 境 ， 根 据 这 个 命令 ID， 可 以 查询 到 具体 的 SQL 语句 和 执行 情况 的 统计 数据 ， 有 些 类 似 于 查询 Oracle 的 V$SQLAREA 视 图 。 
TimesTen 中 ， 更 应 该 关注 执行 时 间 ， 调 用 内 部 存储 过 程 ttsqlcmdcacheinfo2 的 查询 示例 如 下 : 


网 
任 


Command> vertical call ttsqlcmdcacheinfo2 (362104416); 


SQLCMDID: 362104416 
PRIVATE COMMAND CONNECTION ID: 5 

EXECUTIONS: 2 

PREPARES: 2 

REPREPARES: 0 

FREEABLE: 是 

SIZE: 2840 

OWNER: ALEXTT 

QUERYTEXT : select * from tt tab 631 where id=100 for update 
FETCHCOUNT: 鱼 Re 
STARTTIME : 2014-04-27 18:02:05.512000 
MAXEXECUTETIME: 0 

LASTEXECUTETIME: 0 

MINEXECUTETIME: 0 


步骤 4 ”当然 ， 如 果 执 行 效率 不 高 ， 还 是 要 进一步 查看 执行 计划 的 ， 从 中 寻找 可 以 进行 优化 的 地 方 。 查 询 执行 计划 的 存储 过 程 为 tSqlCmdQueryPlan， 示 例如 下 : 


Command> vertical call ttSqlCmdQueryPlan (362104416); 
SQLCMDID: 362104416 


QUERYTEXT : select * from tt tab 631 where id=100 for update 
STEP: <NULL> 

LEVEL: <NULL> 
OPERATION: <NULL> 
TABLENAME: <NULL> 
TABLEOWNERNAME : <NULL> 
INDEXNAME: <NULL> 
INDEXEDPRED: <NULL> 
NONINDEXEDPRED: <NULL> 
SQLCMDID: 362104416 
QUERYTEXT: <NULL> 

STEP: 时 

LEVEL: 

OPERATION: RowLkRangeScan 
TABLENAME: TT TAB 631 
TABLEOWNERNAME : ALEXTT 
INDEXNRAME : TT_TAB 631 
INDEXEDPRED: ( (ID=?;100 ) ) 
NONINDEXEDPRED: 


在 TimesTen 的 应 用 中 ， 对 于 一 些 SQL 语 句 ， 其 中 若 有 较 复 杂 的 表 关联 关系 ， 很 有 可 能 因为 统计 信息 的 不 准确 ， 让 优化 器 错误 评估 表 的 数据 量 ， 而 导致 优化 器 选择 错误 的 表 联 立 顺 序 。 这 样 的 问题 往往 是 
最 致命 的 ， 甚 至 可 以 让 一 条 本 应 几 十 毫秒 完成 的 SQL 跑 上 几 十 分 钟 ， 进 而 导致 CPU 的 压力 ， 拖 累 整 个 数据 库 的 应 用 。 基 于 这 个 原因 ， 我 们 一 直 强调 对 于 TimesTen 应 用 的 SQL 语句 ， 其 多 辑 应 该 尽 可 能 简单 ， 
同时 需要 保证 统计 信息 的 准确 性 。 


6.8.3 ”监控 报告 


众所周知 ， 在 Oracle 数 据 库 中 有 非常 强大 的 性 能 报告 体系 ， 特 别 是 其 中 的 AWR 报 告 ， 更 是 跟踪 、 分 析 、 解 决 性 能 问题 的 利器 ， 这 往往 也 是 其 他 数据 库 所 期 望 拥有 的 。 同 为 Oracle 公 司 产 品 的 TimesTen 
内 存 数据 库 ， 也 引进 了 这 一 利器 ， 虽 然 不 如 AWR 报 告 那样 尽善尽美 ， 但 其 实现 原理 是 一 样 的 ， 功 能 与 作用 也 不 容 小 凯 ， 下 面 就 来 介绍 一 下 这 个 工 . ttStats。 


ttStats 是 一 个 捕获 TimesTen 数 据 库 实时 系统 状态 的 工具 ， 它 可 以 用 来 监测 和 采集 TimesTen 关 键 性 能 指标 ， 并 在 命令 行 中 以 可 读 的 格式 显示 出 来 。 它 也 可 以 产生 某 个 时 点 的 数据 库 性 能 快照 (包括 : 
SQL 语句 执行 性 能 统计 计数 、 检 查 点 和 事务 日 志 操作 、 复 制 和 缓存 集合 行为 、 锁 信息 ， 以 及 其 他 数据 库 行为 和 配置 ) ， 并 自动 对 比 任意 两 个 时 点 快照 ， 呈 现 为 一 个 HTML 格 式 的 性 能 报告 (TTSTATS 报 
告 ) ， 对 数据 库 性 能 调 优 是 非常 有 用 的 ， 也 可 以 称 之 为 TimesTen 的 AWR 报 告 。 


先 来 生成 一 个 TTSTATS 的 报告 吧 ， 方 法 非常 简单 ， 示 例如 下 : 


步骤 1 在 监控 周期 开始 之 前 ， 先 抓 一 个 数据 库 快 照 ， 如 下 所 示 ， 记 录 下 快照 号 为 1。 


$ ttStats -snapshot ttalex 

Connected to TimesTen Version 11.02.02.0005 Oracle TimesTen IMDB version 
T1250 

Snapshot 1 at TYPICAL level was successfully captured. 


步骤 2 执行 批量 并 发 事务 后 ， 再 抓 取 一 个 快照 >， 示例 如 下 : 


$ ttStats -snapshot ttalex 

Connected to TimesTen Version 11.02.02.0005 Oracle TimesTen IMDB version 
T12550: 

Snapshot 2 at TYPICAL level was successfully captured. 


步骤 3 ”此 时 就 可 以 基于 两 个 快照 做 成 一 个 TTSTATS 报 告 了 ， 示 例如 下 : 


$ ttStats -report -outputFile ttalex 1 2.html -snapl 1 -snap2 2 tsalex 


如 图 6-18 所 示 ， 是 一 个 TTSTATS 的 报告 头 展示 ,该 报告 包含 了 SQL 语 句 、 事 务 、 锁 、 复 制 、 日 志 、 检 查 点 、 缓 存 集合 、 缓 存 网 格 等 统计 数据 ， 给 性 能 对 比分 析 提 供 了 有 效 的 参考 。 同 时 ， 也 可 以 使 用 内 
置 存储 过 程 包 TT_STATS 来 对 快照 和 报告 进行 管理 。 


TTSTATS Report Summary omg eine 


Details 


i 
Begin Snap: |1 2014-05-29 11:06.16.000000 = = - 

i End Snap- 2 2014-05-29 11:07:12.000000 Log Bytes [544335 9 534835 

» Statement Statistics Elapsed Time: Ssecs Log Buf Waits 0 0 

Ee Memory Usage and Connections ed ito es 

» PL/SQL Memory Statistics ns 上 

~ Roplicntion sinadies oowies 

”Log Statistics connections.disconnected 5 7 Deletes 0 0 

rr Statistics connections .established client_server 0 0 Inserts 17887 1757 

。 Cache Group Statistice [connections estabishedcoummt [21 [3 | lseect | 1 

* Grid Statistics connections.establshed direct 21 23 Updates 0 0 

* DB Activity Statistics connections.established.first. count 4 4 Hard Parses 1 五 1 

“ Lock Statistics connections.established.threshold_sxceeded 0 0 Total Parses Iz 2 

。 XLA Information db.size.perm_aliocated.kb 262144 262144 Durable Commit 4 0 

* Configuration Parameters db size.perm_high_water_mark.kb 27884 45734 Non-durable Commit |.7 1 
db size perm_in_use kb 27884 45734 Rollback 0 0 
db.size.temp_allocated kb 102400 102400 Rows Per Read 0 |Rows Per Write 0 
db.size temp_high_water_mark.kb 75421 84170 Temp Indexes Created |0 ,Fast Path Log Buffer % 0 
db.size.temp_in_use.kb 75104 77762 

Instance Efficiency Percentage (Target 100%) 
Command Cache Hit % |99 92 |Non-Parse/Execs % |99.91 
Lock Ht % 100 |Log Buffer No Wait % |100 


图 6-18 TTSTATS 性 能 报告 报告 头 


如 果 说 ttStats 是 一 个 周期 性 的 性 能 分 析 工 具 ， 那 么 另 一 个 与 之 名 字 相似 的 工具 ttStatus 则 可 以 算是 一 个 实时 监控 的 工具 ， 该 工具 更 侧重 于 对 进程 的 监控 ， 使 用 起 来 简单 直接 ， 所 见 即 所 得 ， 示 例如 下 : 


$ ttStatus ttalex 

TimesTen status report as of Thu May 24 10:43:47 2014 

Daemon pid 28882 port 53333 instance ttalex 

TimesTen server pid 28892 started on port 53334 

Data store /DataStore/ttalex/ttalex 

There are 14 connections to the data store 

Shared Memory KEY 0xl30cd20e ID 1063518234 

PL/SQL Memory KEY 0x140cd20e ID 1063551003 Address 0x7fa0000000 


Type PID Context Connection Name ConnID 
Cache Agent 23345 0x00000000025574b0 Handler 1 
Cache Agent 23345 0x00000000026d76e0 Timer 2 
Process 4721 0x000000001f289940 ttstatsCmd 3 
Subdaemon 28887 0x0000000019901lde0 Manager 2047 
Subdaemon 28887 0x00002aaad00008c0 HistGC 2043 
Subdaemon 28887 0x00002aaad40008c0 AsyncMV 2039 


RAM residence policy: Manual 

Data store is manually loaded into RAM 

Replication policy : Manual 

Cache Agent policy : Manual 

TimesTen's Cache agent is running for this data store 
PL/SQL enabled. 

Accessible by group ttadmin 

End of report 


虽然 说 TimesTen 数 据 库 中 的 监控 工具 不 如 Oracle 数 据 库 丰 富 ， 功 能 也 不 够 强大 ， 但 是 灵活 应 用 起 来 ， 对 性 能 调 优 和 问题 分 析 都 是 大 有 神 益 的 。 在 Oracle 12c 的 企业 管理 器 (Enterprise Manager) 中 
也 有 添加 TimesTen 的 监控 组 件 ， 可 以 实现 可 视 化 的 性 能 监控 。 


最 后 ， 不 得 不 提 一 下 的 是 一 个 叫做 ttTraceMon 的 工具 ， 它 类 似 于 Oracle 的 事件 跟踪 工具 ， 对 于 追溯 会 话 进程 执行 过 程 的 意义 不 言 而 喻 。 下 面 通过 一 个 实例 来 介绍 一 下 该 工具 的 SQL 事件 跟踪 应 用 吧 。 


步骤 1 通过 ttStatus 工 具 先 明确 要 跟踪 的 会 话 连接 号 (ConnlD) 。 


Type PID Context Connection Name ConnID 
Process 30027 0x000000001498e480 ttalex 


步骤 2 使 用 ttTraceMon 工 具 ， 先 设置 输出 日 志文 件 (outfile 选 项 ) ， 为 了 保证 监控 的 准确 ， 先 行 断 开 所 有 监控 连接 (“connection all off”) ， 再 连接 到 指定 的 会 话 (ConnID=3) 。 然 后 ,设置 跟 
踪 的 级 别 (下 例 中 设置 了 SQL 事 件 的 最 高 跟踪 级 别 “level SQL 5”) ， 此 时 即 开 启 了 会 话 的 SQL 跟踪 ， 相 关 操 作 都 会 被 记录 到 trace.log 文 件 中 ， 当 执行 flush 后 ， 完 成 跟踪 。 


$ ttTraceMon ttalex 
Trace> outfile trace.log 
Trace> connection all off 
Trace> connection 3 on 
Trace> level SQL 5 
Trace> flush 

Trace> 


ttTraceMon 工 具 的 SQL 事 件 跟踪 级 别 说 明 详 见 表 6-13 所 示 。 


表 6-13 ”ttTraceMon 的 SQL 事 件 跟踪 级 别 说 明 


SQL 事件 级 别 


输出 日 志 


容 说 明 


命令 池 中 存在 的 已 解析 但 未 执行 或 出 错 的 命令 ， 同 时 该 级 别 包 


捕获 已 解析 的 SQL 命令 
3 2 级 基础 上 ， 追 加 捕获 已 执行 的 SQL 命令 
3 级 基础 上 ， 追 加 捕获 
括 了 会 话 的 打开 、 关 闭 和 数据 取 回 操作 
5 4 级 基础 上 ， 追加 捕获 一 些 内 部 命令 ， 


比如 用 户 级 的 调试 过 程 


ttTraceMon 工 具 不 仅 能 


6.8.4 ”复制 监控 


在 TimesTen 数 据 库 中 ， 不 论 是 上 


在 复制 的 监控 中 ， 我 们 需要 做 好 以 下 两 点 工作 : 
“ 监控 复制 节点 的 配置 与 健康 状态 ; 


“ 监控 复制 过 程 的 日 志 “ 鸿 沟 ”， 明 确 当前 时 点 数据 是 否 一 致 


复制 的 监控 除了 可 以 使 用 上 述 监控 手段 进行 监控 之 外 ， 也 可 以 是 一 些 独 有 的 工具 ， 而 其 


接口 。 如 下 所 示 ， 可 以 通过 “-showconfig” 参数 来 查看 当前 的 复制 配置 信息 : 


进行 SQL 跟踪 ， 同 样 还 支持 API、LOCK、AGING 等 事件 的 跟踪 。 


于 AWT 缓 存 集合 的 复制 ， 还 是 主 备 库 之 间 的 复制 ， 其 监控 工作 都 是 不 容 忽视 的 ， 因 为 这 关乎 到 数 和 


中 ttRepAdmin 命 令 将 会 是 不 二 之 选 ， 不 仅 可 以 


居 的 一 致 性 和 主 备 库 的 可 用 性 。 


来 独立 查询 ， 也 可 以 谋 套 在 自 定义 的 监控 工具 中 ， 并 提供 调 


$ ttRepAdmin -showconfig ttalex 
Self host "MYACTIVE", port auto, name "TTALEX", LSN 59/10004744, 
timeout 120, threshold 0 


List of objects and subscriptions 


Table : ALEX.TT AWT 601 
Master Name 


Timestamp updates : 一 
Subscriber name 


而 复制 的 健康 运行 状态 ， 则 可 以 使 


“-showstatus” 参 数 来 进行 查看 ， 示 例如 下 。 在 本 例 中 复制 代理 进程 的 状态 为 “Not started” ， 说 明 复 制 进程 未 启动 ， 需 要 关注 。 


$ ttRepAdmin -showstatus ttalex 
Replication Agent Status as of: 2014-05-24 15:12:19 


DSN 3 ttalex 
Process ID : 0 (Not started) 
: manual 


Replication Agent Policy 


在 数据 库 的 复制 过 程 中 ， 日 志 的 “鸿沟 ” 


会 造成 数据 不 一 致 ， 也 就 是 说 主 库 的 日 志 在 备 库 中 没有 及 时 应 


的 “-receiver-list” 参 数 来 查看 日 志 发 送 和 接收 延 时 的 情况 。 本 例 中 ， 主 要 关注 输出 结果 的 Last Msg Sent 栏 位 ， 其 表示 距离 复制 进程 上 次 完成 的 时 间 ( 


Track=1 两 个 复制 进程 ) ， 如 果 时 间 延 误 较 长 ， 则 认为 日 志 “鸿沟 ” 较 大 ， 需 要 关注 。 


$ ttRepAdmin -receiver -list ttalex 


Peer name Host name Port State Proto Track 
_ORACLE MYACTIVE Auto Start 36 下 
Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs 

00:00:08 总 -1:00 = = 1 

Peer name Host name Port State Proto Track 
_ORACLE MYACTIVE Auto Start 36 0 
Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs 

00:00:03 = -1 ,00 -1 -1 1 


， 即 主 备 库 数 据 不 一 致 ， 数 


局 库 切换 则 是 不 可 行 的 。 以 下 示例 中 ， 我 们 可 以 通过 ttRepAdmin 
因为 开启 了 2 路 并 行 复制 ， 所 以 可 以 看 到 Track=0 和 


上 述 示 例 算是 一 个 比较 间接 的 方法 ， 有 没有 更 为 直接 的 方法 呢 ? 当然 有 ， 我 们 可 以 使 
但 比较 遗憾 的 是 该 方法 在 并 发 压力 较 大 的 时 候 ， 有 可 能 造成 一 些 性 能 问题 。 


如 下 所 示 的 “ttXactLog-logAnalyze” 命 令 


进行 日 志 分 析 。 此 时 ， 可 以 看 到 准确 的 延 时 导 


有 务 量 和 日 志 序 列 情况 。 


$ ttXactLog -logAnalyze ttalex 

Summary: 

Total transactions left to replicate: 2 

Total rows left to replicate: 2 

Size of transactions left to replicate: 1.06 KiB 
Size of rows left to replicate: 476.00 B 

Total inserts remaining: 2 

Start LSN = 59.10004744 

End LSN = 59.10039560 


此 外 ， 还 有 一 个 比较 取 巧 的 方法 ， 就 是 自 建 一 个 本 地 监控 表 ， 定 时 记录 一 下 当前 的 时 | 间 和 和 


认同 的 。 


6.8.5 ”自动 刷新 监控 


自动 刷新 的 配置 和 健康 状态 监控 在 前 面 介绍 缓存 集合 的 时 候 已 经 有 涉及 ， 可 以 在 ttlsql 环 境 中 使 


Command> cachegroup cg readonly 601; 
Cache Group CACHEUSER.CG READONLY 601: 
Cache Group Type: Read Only 加 

Autorefresh: Yes 
Autorefresh Mode: Incremental 
Autorefresh State: On 


务 情况 ， 然 后 在 复制 的 发 送 端 和 接收 端 进行 记录 对 比 ， 来 监控 复制 状态 。 


自动 刷新 功能 主要 是 针对 只 读 缓存 集合 和 自 定义 缓存 集合 来 说 的 ， 从 Oracle 到 TimesTen 的 自动 刷新 ， 其 监控 与 复制 监控 有 些 类 似 ， 也 需要 从 健康 状态 和 数 


cachegroup 命 令 直接 查看 ， 示 例如 下 : 


当然 ， 此 方法 并 不 是 所 有 人 都 能 


居 一 致 性 两 方面 来 考虑 。 


Autorefresh Interval: 5 Seconds 
Autorefresh Status: ok 
Aging: No aging defined 
Root Table: ALEX.TT READONLY 601 
Table Type: Read Only 


而 自动 刷新 过 程 是 否 存在 “鸿沟 ”， 需 要 首先 在 刷新 发 起 方 Oracle 数 据 库 中 明确 。 在 Oracle 数 据 库 中 存储 了 不 少 TimesTen 的 数据 字典 表 ， 其 中 表 tt_06_ agent_status 可 以 用 于 监控 缓存 代理 发 起 的 时 间 
和 日 志 序列 ， 如 下 所 示 ， 可 以 依次 来 判断 缓存 代理 进程 的 延 时 情况 。 


SQL> select owner, cgname, bookmark, reportts 
from cacheuser.tt 06 agent status 


3 where status = 'ok'; 
OWNER CGNAME, BOOKMARK REPORTTS 
CACHEUSER CG READONLY 601 3459 27-4 月 -14 15.47.28.000000 


作为 刷新 接收 端的 TimesTen， 也 可 以 监控 到 刷新 应 用 的 情况 。 在 ttlsql 环 境 中 ， 调 用 内 置 存储 过 程 ttCacheAutorefreshStatsGet 可 以 查看 最 近 10 个 刷新 周期 的 刷新 情况 ， 包 括 : 刷新 的 时 间 、 状 态 、 记 
录 行 数 等 信息 。 示 例如 下 : 


Command> call ttCacheAutorefreshStatsGet ('cacheuser', 
> 'cg_ readonly 601°'); 


CGID: 加 3766608 

STARTTIMESTAMP: 2014-04-27 15:48:16.000000 
CACHEAGENTUPTIME: 17636330 

AUTOREFNUMBER: 3511 

AUTOREFDURATION: 0 

STATUS: Complete 

NUMLOGROWS : 0 

TOTALNUMLOGROWS : 0 
AUTORFFLOGFRAGMPNTATIONPCT : 100 
AUTOREFLOGFRAGMENTATIONTS: 2014-04-27 15:45:47.000000 
AUTOREFLOGDEFRAGCNT: 0 


这 里 需要 说 明 一 点 ，Oracle 和 TimesTen 的 SQL 语句 执行 机 制 是 不 一 样 的 ， 在 自动 刷新 过 程 中 ， 并 不 是 Oracle 执 行 什么 ，TimesTen 就 依 样 画 葫芦 地 跟着 执行 什么 ， 这 里 是 有 一 些 语句 的 转换 的 ， 转 换 关 
系 如 表 6-14 所 示 。 


表 6-14 自动 刷新 过 程 的 SQL 语句 转换 关系 


Oracle 语句 TimesTen 语句 说 明 
INSERT INTO ALEX.II UPDATE "ALPX". "TIT READONLY 601™ 当 Oracle 端 发 起 一 次 INSERT 操 
READONLY 601 VALUES (?，?) SET "NAME"” = ? WHERE "ID" = ? 作 的 时 候 ， 通过 触发 器 记录 上 日志， 再 于 


TimesTen 并 自动 刷新 。 刷 新 进程 完 
INSERT INTO “ALEX". ST 成 INSERT 之 前 会 先 发 起 一 次 UPDATE 
READONLY 601" VALUES (?，?) 操作 ， 验 证 数据 的 正确 性 。 换 而 言 之 ， 
oracle 中 的 一 次 INSERT 操 作对 应 
TimesTen 中 的 一 次 UPDATE+INSERT 

操作 


UPDATE TT READONLY 601 UPDATE "ALEX"."TT 当 Oracle 端 发 起 一 次 UPDATE 操 
SET NAME='?' WHERE ID=?; READONLY 601" SET "NAME" = ? 作 ， 在 TimesTen 端的 操作 几乎 是 与 
WHERE "ID" = ? 之 一 对 一 的 关系 但 是 ， TimesTen 中 


UPDATE 操作 是 基于 主键 单条 更 新 ， 当 
oracle 中 一 次 UPDATE 更 新 了 10 行 
记录 ， 那 么 TimesTen 对 应 的 就 是 10 
次 单行 的 更 新 操作 
DELRTE FROM TT READONLY 601 DELETE FT FROM "ALEX"."TT DELETE 操作 的 对 应 关系 与 UPDATE 
WHERE ID=?; READONLY 601" WHERE "ID" = ? 操作 的 机 制 是 一 样 的 。 但 是 ， 细 心 的 读 
者 可 以 发 现 , Oracle 的 DELETE 操作 
在 TimesTen 中 自动 转换 成 DELETE 
ET， 这 也 是 TimesTen 特有 的 一 种 DML 
操作 类 型 


需要 特别 注意 的 是 ， 当 自动 刷新 进程 的 刷新 频率 设置 得 比较 小 (比如 : 5 秒 一 次 ) ,而 Oracle 上 的 DML 操 作 过 程 耗 时 较 长 (比如 : 10 秒 完成 一 个 批 次 的 INSERT 操 作 ) ， 不 能 在 一 个 刷新 周期 内 完成 到 
TimesTen 的 刷新 ， 那 么 在 TimesTen 端 会 滋生 出 匈 余 的 DML 操 作 ， 来 保证 单个 批 次 跨越 多 个 刷新 周期 的 DML 操 作 过 程 的 数据 一 致 性 。 这 一 特点 ， 需 要 TimesTen 对 自动 刷新 过 程 中 密集 的 DML 操 作 付 出 比 
Oracle 更 大 的 开销 ， 因 此 需要 严格 控制 自动 刷新 的 刷新 频率 ， 使 其 尽 可 能 的 大 一 些 。 


6.9 TimesTen 备 份 与 恢复 


相 比 于 Oracle 数 据 库 ，TimesTen 的 备份 工作 可 能 就 显得 不 是 那么 重要 了 。 当 TimesTen 作 为 Oracle 的 缓存 在 使 用 时 ， 按 照 我 们 前 面 介 绍 过 的 架构 设计 ，Oracle 数 据 库 始 终 保存 全 量 的 数据 ， 而 此 时 
TimesTen 即 使 不 进行 任何 的 备份 ， 在 出 现 问题 的 时 候 ， 也 是 可 以 从 Oracle 数 据 库 中 重新 加 载 来 恢复 的 。 而 TimesTen 作 为 独立 数据 库 来 使 用 的 话 ， 备 份 才 更 具有 实际 意义 。 


TimesTen 同 样 提 供 了 多 样 化 的 备份 工具 ， 可 以 支持 传统 方式 的 备份 与 恢复 ， 也 可 以 支持 灵巧 的 数据 迁移 和 导入 导出 。 


6.9.1 数据 库 备份 


先 来 看 一 下 传统 方式 的 备份 与 恢复 吧 ， 对 于 TimesTen 数 据 库 来 说 ， 虽 没有 RMAN 这 样 的 备份 利器 ， 但 其 备份 工具 ttBackup 也 是 能 支持 在 线 完成 全 量 与 增 量 备份 的 ， 避 免 了 非 必要 的 死机 操作 ， 同 时 也 


更 为 高 效 。 


在 TimesTen 的 备份 工具 ttBackup 中 ， 提 供 了 一 个 很 好 的 全 量 备份 或 增 量 备份 自动 判断 的 参数 filelncrOrFull。 当 在 备份 目录 中 ， 没 有 发 现 全 量 备份 集 ， 则 进行 全 量 备份 ， 若 已 存在 ， 则 基于 该 备份 集 自 
动 进行 增 量 备份 。 下 面 通过 一 个 实例 看 一 下 TimesTen 是 如 何 来 实现 备份 的 吧 。 


步骤 1 为 数据 库 ttalex 创 建 一 个 新 的 备份 目录 “/alex/backup”， 并 验证 一 下 当前 Datastore 中 检查 点 文件 和 日 志文 件 信 息 ， 示 例如 下 : 


$ 11 /DataStore/ttalex 
-rw-rw--—-- 1 ttalex ttadmin 
-rw-rw---- 1 ttalex ttadmin 


-rw-rw---- 1 ttalex ttadmin 
-rw-rw---- 1 ttalex ttadmin 
-rw-rw---- 1 ttalex ttadmin 
-rw-rw---- 1 ttalex ttadmin 


80524456 May 
83247104 May 
67108864 May 
67108864 May 
67108864 May 
67108864 May 


25 
25 
25 
25 
25 
a] 


Ls 
11: 
11: 
1 
;39 


11 


11: 


40 
39 
43 
39 


39 


ttalex.ds0 
ttalex.dsl 
ttalex.1og59 
ttalex.res0 
ttalex.resl 
ttalex.res2 


步骤 2 使 用 ttBackup 工 具 开 始 数 据 库 ttalex 的 备份 。 


的 第 一 次 备份 ， 故 为 全 量 备份 。 


如 下 示例 ， 设 置 备份 目录 位 置 为 -dir/alex/backup”， 并 指定 参数 “-type filelncrOrFull”， 自 动 判断 是 全 量 或 是 增 量 备份 ， 因 为 是 在 该 目录 下 


$ ttbackup -type fileIncrOrFull -dir /alex/backup ttalex 
Backup started http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/OEBPS/Text/... 


Backup complete 


步骤 3 ”因为 ttBackup 工 具 是 基于 文件 复制 方式 的 备份 ， 所 以 备份 速度 非常 快 ， 完 成 后 验证 一 下 备份 目录 下 的 备份 文件 。 在 下 面 的 示例 中 ， 可 以 看 到 ttalex.0.bac 文 件 即 为 检查 点 文件 ttalex.ds0 的 备 


份 ， 而 ttalex.0.bac59 文 件 是 基于 检查 点 文件 ttalex.ds0 的 日 志文 件 备份 ， 对 应 于 事务 日 志 ttalex.log59。 


$ 11 /alex/backup 
total 0944 


-- 1 ttalex ttadmin 


1 ttalex ttadmin 80527360 May 25 11:44 ttalex.0.bac 
1 ttalex ttadmin 67108864 May 25 11:44 ttalex.0.bac59 


720 May 25 11:44 ttalex.sta 


为 什么 是 基于 检查 点 文件 ttalex.ds0 进 行 备份 的 ， 而 不 是 ttalex.ds1 文 件 呢 ? 这 是 因为 ttalex.ds1 是 当前 检查 点 文件 ， 备 份 工具 会 选择 两 个 检查 点 文件 中 当前 非 活跃 的 那个 进行 全 量 备份 ， 因 为 日 志文 件 同 
时 进行 了 备份 ， 所 以 不 必 担心 数据 丢失 。 


步骤 4 ” 当 进 行 一 些 事务 操作 后 ，TimesTen 的 在 线 村 


务 


日 志 有 所 增长 了 ， 多 了 ttalex.log60 和 ttalex.log61， 如 下 所 示 : 


$ 11 /DataStore/ttalex 

-rw-rw---- 1 ttalex ttadmin 
ttalex ttadmin 
ttalex ttadmin 
ttalex ttadmin 
ttalex ttadmin 
ttalex ttadmin 
ttalex ttadmin 
ttalex ttadmin 


PpPpPPPP 


80524456 May 
83247104 May 
67108864 May 
67108864 May 
26249216 May 
67108864 May 
67108864 May 
67108864 May 


25 
25 
25 
25 
25 
25 
25 
4 


11: 
了 于 
iL: 
11: 
Ls 
ls 
11: 
11: 


40 
39 
43 
45 
45 
39 
39 
39 


ttalex.ds0 
ttalex.dsl 
ttalex.1og59 
ttalex.1og60 
ttalex.1og61 
ttalex.res0 
ttalex.resl 
ttalex.res2 


此 时 再 次 进行 备份 会 如 何 呢 ? 


步骤 5 ”如 下 所 示 ， 采 用 与 步骤 2 同样 的 方式 和 人 参数， 再 次 进行 备份 。 此 次 备份 过 程 很 快 就 完成 了 ， 因 为 进行 的 不 再 是 全 量 备份 ， 而 是 增 量 的 了 。 


$ ttbackup -type fileIncrOrFull -dir /alex/backup ttalex 
Backup started http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/OEBPSVText/... 


Backup complete 


步骤 6 ”验证 备份 目录 可 以 看 到 ， 备 份 集 新 增 了 两 个 日 志 备 份 文件 ttalex.0.bac60 和 ttalex.0.bac61， 而 其 他 备份 文件 时 间 戳 并 未 发 生 改 变 。 


$ 11 /alex/backup 
total 140944 
—rw: ttalex ttadmin 
ttalex ttadmin 
ttalex ttadmin 
ttalex ttadmin 
ttalex ttadmin 


80527360 May 
67108864 May 
67108864 May 
27416576 May 

720 May 


25 
25 
a 
25 
25 


:4 
:4 
:48 
:48 
$4 


ttalex.0.bac 
ttalex.0.bac59 
ttalex.0.bac60 
ttalex.0.bac61 
ttalex. sta 


ttBackup 备 份 工 具 ， 其 备份 机 制 是 基于 文件 复制 方式 来 进行 的 ， 可 以 概括 为 : 


“ 全 量 备份 : 对 非 当 前 活跃 检查 点 文件 及 其 对 应 日 志文 件 进行 备份 ; 


“ 增 量 备份 : 判断 上 次 备份 时 点 ， 备 份 该 时 点 之 后 产生 的 日 志文 件 。 


6.9.2 ”数据 库 恢复 


有 备份 自然 就 有 恢复 ，ttBackup 工 


1. 全 量 恢复 


先 来 看 一 下 全 量 恢复 吧 ， 这 种 类 型 的 恢复 会 比较 简 自 


的 备份 集 则 需要 依靠 ttRestore 工 具 来 进行 恢复 。ttRestore 同 样 不 能 像 RMAN 一 样 功能 强大 ， 但 它 也 可 以 支持 全 量 的 恢复 和 基于 日 志文 件 的 不 完全 恢复 。 


和 R， 备 份 了 什么 就 直接 恢复 什么 。 下 面 是 一 个 基于 上 述 备份 而 进行 的 全 量 恢复 实例 展示 。 


步骤 1 在 完成 备份 后 ， 将 其 中 的 表 tt_tab_630 删 除 ， 以 作为 恢复 是 否 成 功 的 标志 。 


Command> tables; 
ALEXTT.TT TAB 630 


Command> drop table tt tab 630; 


Command> tables; 
0 tables found. 


步骤 2 ”强制 删除 检查 点 文件 和 日 志文 件 后 ， 室 


和 启 Daemon 主 进程 ， 然 后 使 用 恢复 工具 ttRestore 将 备份 目录 “/alex/backup” 下 的 全 量 备份 和 增 量 备份 集 进行 全 量 恢 复 。 其 中 ， 参 数 “-fname” 标 示 


备份 集 文件 的 前 缀 (默认 为 数据 库 名 ) ， 而 参数 “-noconn” 表 示 恢 复 完成 后 不 立刻 开启 数据 库 连 接 。 示 例如 下 : 


$ ttrestore -noconn -dir /alex/backup -fname ttalex ttalex 
Restore started http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/... 
Restore complete 


步骤 3 ”全 量 恢复 完成 后 ， 可 以 看 到 步骤 1 中 被 删除 的 表 tt_tab_630 被 成 功 恢复 了 ， 全 量 恢复 成 功 了 。 


Command> tables; 
ALEXTT.TT_TAB 630 


2. 基 于 日 志 前 滚 的 不 完全 恢复 


备份 工作 是 按照 特定 的 时 间 点 来 进行 的 ， 如 果 进 行 全 量 恢复 可 能 会 导致 备份 时 点 到 故障 时 点 之 间 的 数据 丢失 。 幸 运 的 是 ， 如 果 保 留 这 两 个 时 点 之 间 的 日 志文 件 ， 则 TimesTen 会 在 全 量 恢复 后 ， 自 动 前 滚 
应 用 这 些 日 志文 件 ， 来 补偿 该 两 个 时 点 的 数据 。 在 Oracle 数 据 库 中 ， 这 种 恢复 方式 称 为 “基于 时 间 点 的 不 完全 恢复 ”， 但 TimesTen 做 不 到 基于 时 间 点 的 粒度 ， 只 能 做 到 基于 日 志文 件 的 粒度 ， 故 称 之 为 “ 基 
于 日 志 前 滚 的 不 完全 恢复 ”。 


如 图 6-19 所 示 ， 当 前 最 近 的 备份 时 点 在 日 志文 件 log61 处 ， 而 故障 时 点 在 log65 发 生 ， 那 么 从 log61 到 log64 之 间 的 数据 就 成 了 关注 的 重点 。 这 期 间 ， 数 据 库 删 除了 表 tt_tab 630， 并 创建 了 表 
tt tab_641 (外 加 进行 了 批量 的 事务 ) ， 这 部 分 数据 变化 是 不 能 丢失 的 。 因 为 Iog65 是 故障 时 点 的 日 志 ， 这 个 日 志文 件 是 不 能 用 于 恢复 的 ， 比 较 好 的 情况 是 将 log64 作 为 预期 的 恢复 时 点 。 


备份 时 点 恢复 时 点 故障 时 点 


log59 log60 log6l1 log03 log64 


删除 表 tt tab 630 
创建 表 tt_ tab 641 


图 6-19 基于 日 志 前 滚 的 不 完全 恢复 


对 表 tt_tab 641 执 行 批量 事务 


数据 库 不 完全 恢复 的 过 程 与 全 量 恢复 并 没有 太 大 差别 ， 都 是 通过 ttRestore 工 具 来 进行 的 。 在 完成 全 量 恢复 之 后 ， 不 要 立刻 开启 数据 库 ， 将 数据 库 设置 为 手工 启动 方式 ， 并 将 备份 时 点 到 恢复 时 点 的 日 志 
(log61 至 log64) 全 部 恢复 到 DataStore 中 ， 然 后 开启 数据 库 加 载 进程 。 此 时 ， 会 发 现 加 载 进程 会 比 正常 情况 要 慢 一 些 ， 即 是 在 进行 不 完全 恢复 。 数 据 库 成 功 加 载 后， 发 现 表 tt_tab_630 不 见 了 ， 而 表 
tt tab_641 被 恢复 了 ， 不 完全 恢复 成 功 。 恢 复命 令 示例 如 下 : 


$ ttAdmin -ramPolicy manual ttalex 
$ cp ttalex.1og61 ttalex.1og62 /DataStore/ttalex 
$ cp ttalex.1og62 ttalex.1og64 /DataStore/ttalex 
$ ttAdmin -ramLoad ttalex 
Command> tables; 

ALEXTT .TT TAB 641 
table found. 


3. 跨 越 增 量 备份 时 点 的 不 完全 恢复 


以 上 两 种 方式 的 恢复 都 是 基于 故障 发 生 的 数据 库 恢复 ， 基 于 日 志 前 滚 的 不 完全 恢复 几乎 可 以 做 到 最 大 限度 不 丢失 数据 。 然 而 ， 有 的 时 候 ， 我 们 在 做 数据 库 操作 会 发 生 一 些 逻 辑 上 的 错误 或 者 说 是 操作 失 
误 ， 那 在 TimesTen 中 是 否 可 以 像 Oracle 一 样 实现 Flashback 的 回 退 呢 ? 遗憾 的 是 ， 在 TimesTen 中 仅 能 实现 基于 数据 库 层级 的 Flashback 功 能 ， 这 种 恢复 方式 ， 我 们 且 称 之 为 “跨越 增 量 备份 时 点 的 不 完全 恢 


如 图 6-20 所 示 ， 在 log66 时 点 ， 数 据 库 进 行 了 全 量 备份 ， 而 最 后 一 次 增 量 的 备份 时 点 在 log71 处 ， 这 期 间 在 log68 处 ， 进 行 了 表 tt_tab_641 的 删除 和 表 tt_tab_650 的 创建 等 操作 ， 事 后 发 现 这 些 操作 是 错 
误 的 ， 需 要 回 退 ， 然 而 备份 的 时 点 已 经 来 到 了 log71 处 ， 是 否 能 够 恢复 呢 ? 


最 后 增 量 


全 量 备份 时 点 恢复 时 点 备份 时 点 


log66 log67 log68 log69 log70 log71 log72 


删除 表 tt_ tab 641 
i 对 表 tt_tab_650 执 行 批量 事务 


图 6-20 ”跨越 增 量 备份 时 点 的 不 完全 恢复 


此 时 ， 就 表现 出 增 量 备份 的 优势 了 。 当 前 期 望 的 恢复 时 点 在 log68 处 ， 在 全 量 备份 时 点 log66 之 后 ， 这 是 可 以 进行 恢复 的 ， 否 则 就 无 法 恢复 了 。 这 次 期 望 的 不 完全 恢复 过 程 将 跨越 最 后 的 增 量 备份 时 点 
log71， 同 样 也 是 需要 先 做 一 次 全 量 恢复 的 ， 恢 复 时 点 到 log71， 当 删除 掉 不 必要 的 日 志 (log69 至 log72) 后 再 进行 数据 库 加 载 ， 表 tt_tab_641 得 以 成 功 恢复 。 恢 复命 令 示例 如 下 : 


$ ttAdmin -ramPolicy manual ttalex 
$ rm ttalex.1og69 ttalex.10g70 ttalex.1og71 ttalex.1og72 
$ ttAdmin -ramLoad ttalex 
Command> tables; 
ALEXTT.TT TAB 641 
1 table found. 


6.9.3 ”数据 迁移 


TimesTen 在 提供 备份 与 恢复 工具 的 同时 ， 也 提供 了 方便 的 数据 迁移 工具 ， 主 要 包括 以 下 两 种 : 


“ ttBulkCp: 在 TimesTen 数 据 表 和 文本 文件 间 相 互 迁 移 数据 ; 


“ ttMigrate: 在 TimesTen 数 据 表 和 二 进 制 文件 间 相 互 迁 移 数据 ， 类 似 于 Oracle 的 数据 泵 工具 。 


1.ttBulkCp 工 


先 来 说 说 ttBulkCp 工 具 ， 它 可 以 将 TimesTen 的 表 导出 成 文本 文件 ， 同 样 也 可 以 将 特定 格式 的 文本 文件 导入 到 TimesTen 的 表 中 。 最 为 可 贵 的 是 ， 其 导出 的 文本 文件 是 非常 易于 阅读 和 编辑 的 ， 使 得 该 工 
具 在 异 构 数据 库 间 进行 数据 迁移 意义 重大 。 


同样 ， 通 过 一 个 实例 来 演示 一 下 ttBulkCp 工 具 的 使 用 吧 。 通 过 ttBulkCp 工 具 将 表 alextt.tt_tab_650 导 出 到 文本 文件 tt_tab_650.tbl 中 ， 其 中 需要 指定 参数 “-o”， 以 声明 是 导出 表 到 文件 (如果 是 从 文件 
到 表 的 导入 ， 则 指定 参数 “-i”) ， 参 数 “-connstr” 设 置 为 需 连 接 的 数据 库 ， 如 下 所 示 。 


$ ttBulkCp -Oo -connstr "dsn=ttalex" alextt.tt tab 650 tt tab 650.tbl 
1000000/1000000 rows copied 


导出 过 程 相对 来 说 是 非常 快 的 ， 而 且 不 会 产生 锁 争 用 ， 其 导出 的 文本 文件 格式 如 下 所 示 ， 包 含 了 表 的 定义 和 数据 ， 具 有 很 高 的 可 读 性 。 如 果 需 要 导入 到 Oracle 中 ， 也 只 需要 略 加 修改 ， 就 可 以 使 
SQL*Loader 方 便 地 导入 。 但 是 ， 该 方法 的 局 限 性 在 于 仅 方 便 进 行 单 表 处 理 。 


$ view tt _ tab 650.tbl 
##ttBulkCp: CHARACTERSET=ZHS1 6GBK 


# 
# ALEXTT.TT TAB 650, 2 columns, dumped Fri Apr 27 21:59:51 2014 


# columns: 

# 二 汪汪 NUMBER 

# 2. NAME VARCHAR2 (100 BYTE) 
# end 

# 


1,"TimesTen" 
2,"TimesTen" 


999999, "rimesTenn 
1000000, "TimesTen" 
# 1000000/1000000 rows copied 


使 用 ttBulkCp 工 具 进 行 导入 的 时 候 ， 因 为 TimesTen 中 表 是 在 线 的 ， 需 要 在 导入 过 程 中 进行 锁 保 护 。 默 认 情 况 下 ，TimesTen 对 该 工具 的 导入 是 添加 一 个 表 级 锁 ， 在 完成 导入 之 前 ， 整 表 被 锁定 ， 对 应 
连接 排他 ， 对 于 并 发 处 理 要 求 高 的 TimesTen 数 据 库 来 说 ， 这 是 比较 难以 接受 的 。 如 下 例 所 示 ， 将 100 万 行 的 记录 从 文本 文件 tt_tab_650.tbl 导 入 到 表 alextt.tt_tab_650 中 ， 其 过 程 通过 ttXactAdmin 工 具 监 
控 ， 可 以 看 到 表 级 排他 锁 。 


$ ttBulkCp -i -connstr "dsn=ttalex" alextt.tt tab 650 tt tab 650.tbl 
tt tab 650.tbl: 

~ 1000000 rows inserted 
1000000 rows total 
$ ttXactAdmin -tbl alextt.tt tab 650 -connstr DSN=ttalex|more 
Outstanding locks on table ALEXTT.TT TAB 650 
Resource ResourceID PID Context TransactId Mode SqlCmdID 
Table 1798064 23164 ”0x17a28180 1.5442 WW 350949008 


如 果 需 要 保证 并 发 数据 库 系统 的 可 用 性 ， 我 们 需要 将 表 级 锁 更 换 成 行 级 锁 ，TimesTen 支 持 该 更 换 。 如 下 例 所 示 ， 在 默认 的 基础 上 追加 两 个 导入 参数 : 


: -notblLock: 表示 导入 过 程 不 使 用 表 级 锁 ， 使 用 行 级 锁 替 代 ; 


. -xp N: 表示 导入 过 程 每 N 行 记录 提交 一 次 。 


此 时 ， 监 控 结 果 中 看 不 到 表 级 锁 了 ， 取 而 代 之 的 是 众多 的 行 级 锁 ， 因 为 我 们 设置 了 每 1000 行 提交 一 次 ， 所 以 行 级 锁 数量 最 多 不 会 超过 1000 个 。 这 些 设置 都 是 在 导入 过 程 中 保证 数据 库 并 发 处 理 的 可 上 


$ ttBulkCp -i -connstr "dsn=ttalex" -xp 1000 -notblLock 
alextt.tt tab 650 tt tab 650.tbl 

tt tab 650.tbl: 

~ 1000000 rows inserted 
1000000 rows total 
$ ttXactAdmin -tbl alextt.tt tab 650 -connstr DSN=ttalex|more 

Outstanding locks on table ALEXTT.TT TAB 650 
Resource ResourceID PID Context TransactId Mode SqlCmdID 


Table 1798064 20579 0x1634180 1.3774 IXn 350942032 
Row BMUFVUAAABUAWAAKBG 20579 Ox1634180 2 1.3774 Xn 350942032 
Row BMUFVUAAABrAWAAEDF 20579 0x1634180 1.3774 xn 350942032 
Row BMUFVUAAABrAWAADDF 20579 0x1634180 1.3774 Xn 350942032 


898 locks found for this resource 


然而 ， 即 使 有 锁 的 优化 来 保证 并 发 处 理 ， 也 是 不 推荐 在 正常 业务 时 间 内 进行 大 批量 的 导入 操作 ， 需 要 进行 必要 的 风险 控制 。 


2.ttMigrate 工 具 


ttMigrate 工 具 更 多 时 候 是 用 于 批量 表 和 整 库 的 数据 导入 和 导出 操作 ， 它 有 些 类 似 于 Oracle 的 数据 泵 工具 ， 导 出 的 文件 是 二 进 制 保存 的 ， 不 具有 可 读 性 。 


如 下 所 示 ， 通 过 ttMigrate 工 具 整 库 导出 ttalex 库 到 文件 ttalex.dmp。 该 工具 相对 于 ttBulkCp 来 说 ， 操 作 效 率 会 更 高 一 些 ， 能 够 方便 地 应 用 于 数据 库 级 别 的 迁移 、 


和 升级 工作 。 


$ ttmigrate -C -connstr "DSN=ttalex" ttalex.dmp 


如 果 需 要 通过 二 进 制 的 dump 文 件 导 入 数据 库 ， 则 需要 进行 如 下 所 示 操作 。 


$ ttmigrate -r -connstr "DSN=ttalex" ttalex.dmp 


纵 观 TimesTen 的 几 种 备份 恢复 的 工具 ， 其 功能 与 效率 都 不 能 与 Oracle 的 RMAN 工 具 相 媲美 ， 但 是 对 轻 量 级 的 TimesTen 内 存 数 据 库 来 说 ， 已 经 足够 了 。 在 制定 数据 库 备份 策 略 的 时 人 息 ， 需 要 特别 注意 仅 
备份 必须 要 备份 的 ， 能 不 备份 的 尽量 不 要 备份 ， 使 用 ASP 或 者 网 格 高 可 用 架构 来 作为 替代 ， 避 免 增 加 不 必要 的 数据 库 性 能 损耗 。 


6.10 TimesTen 高 并 发 场景 


说 一 干道 一 万 ，TimesTen 是 否 有 使 用 价值 ， 还 是 需要 实际 来 检验 的 。 很 多 时 候 ， 我 们 常常 会 听 说 何 种 架构 何 种 产品 ， 带 来 性 能 多 少 的 提升 。 这 些 无 疑 是 商家 的 嘻 头 ， 不 足 为 信 ， 
也 没有 万 能 的 产品 ， 只 有 万 变 的 需要 和 场景 。TimesTen 的 应 用 也 不 例外 ， 如 果 场 景 的 选择 不 当 ， 其 性 能 反而 不 如 Oracle。 


加 


为 没有 万 能 的 架构 ， 


6.10.1 场景 选择 


在 6.1.2 节 中 ， 我 们 从 较 高 的 层面 介绍 了 TimesTen 的 的 应 用 场景 ， 而 实际 应 用 中 ， 我 们 如 何 去 判 断 和 选择 呢 ? 可 以 参考 如 图 6-21 的 流程 所 示 ， 大 致 可 以 简单 地 总 结 出 以 下 几 条 : 


Oracle 优 化 


抽取 影响 最 大 的 SQL 


单 体 并 发 对 比 测试 


应 用 场景 对 比 测试 


使 用 TimesTen 


6-21 TimesTen 场 景 选择 


"是否 可 以 在 Oracle 中 优化 完成 2 如 果 能 ， 则 直接 进行 Oracle 优 化 ， 因 为 引进 TimesTen 的 应 用 ， 其 各 方 成 本 都 是 较 大 的 。 


“ 是 否 高 并 发 的 场景 ? 仅 将 可 能 发 生 高 并 发 的 场景 选取 出 来 ， 不 可 以 为 了 图 方便 ， 全 部 场景 都 拿 来 尝试 TimesTen。 


“ 接 下 来 就 是 评估 的 工作 了 ， 先 将 场景 中 影响 最 大 、 最 可 能 产生 问题 的 单条 SQL 或 者 几 个 SQL 抽 取出 来 ， 进 行 单 体 的 并 发 对 比 测试 ， 确 定 其 效果 是 否 优 于 Oracle。 如 果 优 于 Oracle 则 继续 评估 ， 否 则 退回 
进行 Oracle 的 优化 工作 。 


: 完成 单 体 评估 后 再 进行 整体 评估 ， 看 整体 的 应 用 场景 在 TimesTen 中 运行 效果 是 否 能 够 达到 预期 ， 如 果 能 达到 则 使 用 TimesTen。 和 否则 退回 进行 Oracle 的 优化 工作 。 


综合 来 看 ，TimesTen 数 据 库 的 应 用 场景 选择 并 不 是 一 项 简单 的 工作 ， 如 果 在 评估 阶段 没有 做 好 ， 在 实际 应 用 中 将 面临 比 Oracle 更 多 、 更 严重 的 问题 ， 因 为 TimesTen 的 功能 不 如 Oracle 强 大 ， 其 对 于 性 
能 要 求 比较 “敏感 ”， 做 不 到 Oracle 一 样 的 “包容 性 ”。 


6.10.2 ”并 发 场景 测试 


顾名思义 ，TimesTen 内 存 数据 库 应 用 可 预期 的 是 10 倍 性 能 的 提升 ， 而 这 往往 也 是 因 场 景 不 同 而 各 异 的 。 而 达到 多 少 倍 的 性 能 提升 是 可 以 视 为 比较 理想 的 应 用 呢 ? 下 面 是 我 做 的 一 个 应 用 场景 的 并 发 测试 
案例 。 图 6-22 所 示 为 集中 抓 取 个 别 几 条 可 能 造成 问题 的 并 发 度 较 高 的 SQL 语 句 进行 的 单 体 测试 结果 ， 可 以 看 到 有 5~10 倍 的 性 能 提升 (TimesTen 的 每 秒 事 务 数 TPS 约 为 2500 左 右 ，Oracle 则 约 为 300 左 
右 ) ， 这 表明 我 们 是 可 以 接受 的 ， 并 进行 下 一 步 的 对 比 测试 。 


单 体 并 发 测试 TPS 趋 势 对 比 
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图 6-22 TimesTen 单 体 并 发 测试 


如 图 6-23 所 示 ， 在 进行 应 用 场景 的 整体 测试 时 ， 同 样 可 以 看 到 5~10 倍 的 性 能 提升 (TimesTen 的 TPS 约 为 1100 左 右 ，Oracle 则 约 为 130 左 右 ) ， 进 一 步 验证 该 场景 是 适合 使 用 TimesTen 内 存 数 据 库 的 。 


值得 注意 的 是 ， 在 对 比 测试 过 程 中 ， 不 能 简单 地 将 Oracle 的 原始 SQL 在 TimesTen 上 运行 ， 这 样 的 效果 并 不 会 太 好 ， 需 要 进行 改写 和 优化 成 TimesTen 较 为 适应 的 SQL 语句 ， 方 能 达到 更 好 的 效果 。10 倍 
的 性 能 提升 ， 也 不 是 必需 的 ， 仅 是 一 个 指导 值 ， 对 于 一 些 高 并 发 的 场景 ， 甚 至 可 以 企及 更 高 的 性 能 提升 。 


应 用 场景 并 发 测试 
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图 6-23 TimesTen 应 用 场景 并 发 测试 


6.11 本 章 小 结 


纵 观 本 章 ， 主 要 介绍 的 是 TimesTen 内 存 数据 库 的 由 来 背景 、 安 装配 置 、 缓 存 集合 管理 、 高 可 用 架构 和 性 能 优化 管理 等 内 容 ， 为 Oracle 数 据 库 的 纵向 和 横向 扩展 提供 了 第 一 个 重要 的 解决 方案 。 在 下 一 章 
中 ， 我 们 将 给 读者 介绍 使 用 GoldenGate 构 建 数据 库 群 ， 将 原本 松散 的 Oracle 数 据 库 整合 起 来 ， 形 成 一 套数 据 库 体 系 ， 使 得 纵横 扩展 更 为 多 样 化 。 


第 7 章 ”GoldenGate 构 建 数据 库 群 


本 章 要 点 : 


: GoldenGate 概 述 ， 介 绍 使 用 GoldenGate 架 构 高 并 发 数据 库 系 统 的 思路 。 


“ 开始 使 用 ， 介 绍 GoldenGate 的 安装 配置 、 监 挖 和 链 路 原理 。 


: 高 级 应 用 ， 简 单 介 绍 GoldenGate 的 高 级 应 用 。 


“ 异 构 数据 库 群 ， 使 用 GoldenGate 集 成 异 构 数 据 库 环境 。 


关于 Oracle 数 据 库 的 复制 工具 ， 从 最 初 的 高 级 复制 (Advanced Replication) ， 到 流 复制 (Stream Replication) ， 再 到 最 新 的 GoldenGate 复 制 ， 可 谓 是 一 步 一 次 飞越 ， 每 一 种 新 复制 工具 的 出 现 都 
是 革命 性 的 ， 特 别 是 GoldenGate 的 出 现 ， 基 本 上 算是 “一 统 江湖 ”了 。Oracle 在 推出 GoldenGate 之 后 ， 陆 续 终结 了 高 级 复制 和 流 复制 ， 取 而 代 之 的 GoldenGate 不 仅 全 面 优化 了 Oracle 数 据 库 本 身 的 优化 
技术 ， 更 实现 了 跨 平台 和 异 构 数据 库 之 间 的 数据 复制 。 当 然 ， 其 与 Oracle 数 据 库 的 兼容 性 也 是 其 他 第 三 方 复 制 工具 所 难以 企及 的 。 


对 于 这 样 一 个 革命 性 的 数据 复制 工具 GoldenGate， 完 全 可 以 单独 为 其 出 一 本 书 去 讲述 ， 我 们 很 难 在 一 章 的 内 容 中 讲述 得 深入 且 面 面 俱 到 。 在 本 章 中 ， 我 们 仍 将 立足 于 高 并 发 数据 库 应 用 系统 ， 通 过 
GoldenGate 复 制 工具 ， 建 立 多 数据 库 共同 作用 的 数据 库 群 ， 也 就 是 说 给 “数据 库 森林 体系 ”建立 有 效 的 关联 。 


7.1 GoldenGate 概 述 


如 果 将 GoldenGate 定 位 成 一 个 数据 实时 复制 工具 ， 显 然 是 低估 了 它 的 能 力 ， 也 是 不 够 准确 的 。 比 较 准 确 的 定位 应 该 是 一 套 比较 完整 的 实时 数据 整合 平台 ， 或 者 说 是 实时 数据 集成 平台 。 


与 TimesTen 一 样 ，GoldenGate 也 不 是 Oracle 原 生态 的 产品 。GoldenGate 原 为 一 家 数据 复制 领域 的 专业 公司 ， 创 建 于 1995 年 ， 总 部 在 美国 旧金山 。 全 球 超 过 4000 个 安装 许可 ， 分 布 在 政府 、 银 行 、 制 
造 、 传 媒 、 电 信 、 证 券 、 医 疗 和 零售 等 各 大 行业 ， 其 中 有 多 个 全 球 财富 500 强 企业 。2009 年 被 Oracle 收 购 。 自 此 ，GoldenGate 给 Oracle 的 数据 整合 方案 带 来 了 在 异 构 平台 的 、 快 速 的 、 可 扩展 的 、 实 时 的 
数据 整合 能 力 ， 同 时 为 应 用 和 数据 库 提 供 了 在 线 升 级 、 迁 移 的 能 


7.1.1 小 核心 , 大 外 围 


“小 核心 ， 大 外 围 ”， 起 初 是 一 个 软件 架构 的 概念 ， 但 同样 适用 于 数据 库 领 域 。 在 传统 的 架构 设计 中 ， 大 家 倾向 于 将 应 用 和 数据 集中 起 来 ， 做 成 一 个 大 核心 ， 这 样 便于 管理 和 容 灾 等 。 然 而 ,在 “ 微 应 
”盛行 的 互联 网 时 代 ， 在 做 数据 库 架构 设计 时 ， 需 要 驾驭 好 互联 网 思维 ,打破 一 些 传统 设计 理念 。 


现 如 今 ， 众 多 传统 行业 的 公司 也 开始 搭建 自己 的 电子 商务 平台 ， 甚 至 成 立 子 公司 专攻 其 业务 的 互联 网 化 。 此 时 ， 再 拿 做 传统 业务 那 一 套 似乎 就 有 些 不 合 时 宜 了 ， 但 是 完全 抛弃 传统 ， 也 是 做 不 到 的 。 基 
于 这 个 背景 ，“ 小 核心 ， 大 外 围 ”的 设计 思想 就 能 很 好 地 帮 到 我 们 了 。 


如 图 7-1 所 示 ， 在 传统 的 设计 模型 中 ， 通 常会 将 不 同 的 应 用 或 者 功能 模块 集中 在 一 个 数据 库 中 ， 所 有 的 系统 都 只 需要 访问 这 个 数据 库 就 能 完成 业务 需求 。 为 了 满足 日 趋 增加 的 业务 量 和 数据 库 访问 压力 ， 
不 得 不 进行 硬件 扩展 和 数据 库 纵向 扩展 。 然 而 ， 对 于 并 发 要 求 高 的 线 上 应 用 ， 这 无 疑 是 不 够 的 。 此 时 ， 就 需要 做 一 些 架构 上 的 转变 ， 通 过 小 核心 大 外 围 来 进行 优化 。 所 谓 小 核心 大 外 围 ， 并 不 是 将 核心 做 
小 ， 而 是 将 外 围 做 大 。 如 图 7-1 所 示 ， 我 们 首先 需要 明确 哪些 业务 会 是 核心 中 的 核心 ， 来 将 其 提炼 出 来 ， 完 成 核心 的 重 定义 ， 或 者 说 是 “减肥 ”。 很 显然 ， 结 算 业 务 将 是 核心 中 的 核心 ， 这 样 就 将 其 提炼 出 
来 ， 使 之 与 其 他 业务 尽 可 能 地 解 厢 ， 形 成 新 的 小 核心 。 而 其 他 业务 也 相互 解 厢 ， 做 成 独立 的 外 围 系统 ， 每 个 外 围 系 统 都 包含 其 独立 的 逻辑 关系 ， 对 应 独立 的 业务 应 用 。 然 而 ， 在 传统 行业 应 用 中 ， 要 做 到 完 
全 解 看 是 不 可 能 的 ， 此 时 系统 的 耦合 关系 通过 与 小 核心 的 交互 来 实现 。 对 于 数据 库 架构 来 说 ， 这 种 交互 就 意味 着 是 数据 的 交互 ， 可 以 通过 GoldenGate 工 具 来 实现 。 


传统 模型 小 核心 大 外 围 


图 7-1 小 核心 大 外 围 转 变 


这 种 架构 的 转变 ， 虽 然 增 加 了 数据 库 运 维 的 成 本 ， 但 是 对 于 数据 库 的 应 用 和 高 并 发 处 理 ， 甚 至 纵横 扩展 都 是 有 百 利 而 无 一 害 的 。 


而 使 用 GoldenGate 来 实现 数据 的 交互 ， 更 能 不 受 数据 库 异 构 环境 和 异 构 平台 的 限制 ， 其 所 支持 的 数据 库 产品 和 操作 系统 平台 详 见 表 7-1 所 示 。 


表 7-1 GoldenGate 支 持 的 数据 库 和 操作 系统 


数据 库 产品 操作 系统 平台 


支持 源 端 和 目标 端 Oracle Windows 2000, 2003, XP, 2008 
DB2 Linux 
SQL Server Sun Solaris 
Sybase ASE HP NonStop 
Teradata HP-UX 
Enscribe HP TRU64 
SQL/MP HP OpenVvMs 
SQL/MX IBM AIX 
MySQL IBM z/OS 
TimesTen 

仅 支 持 目 标 端 HP Neoview 
Netezza 
Greenplum 


ETL products 


JMS message queues 


其 他 支持 ODBC 的 数据 库 


7.1.2 ”GoldenGate 应 用 场景 


说 起 GoldenGate 的 应 用 场景 ， 可 以 简单 地 归纳 为 如 下 两 个 方面 : 


可 用 容 灾 ; 


可 


“ 准 实时 数据 (复制 ) 集成 。 


说 起 Oracle 数 据 库 的 容 灾 ， 相 信 大 家 第 一 反应 应 该 都 是 Data Guard。 不 错 ， 到 目前 来 说 ，Data Guard 仍 是 Oracle 数 据 库容 灾 方 案 的 首选 ， 也 是 众多 用 户 多 方 验证 过 的 成 熟 方案 。 那 么 ,与 之 相 
比 ，GoldenGate 有 什么 优势 吗 ? 不 论 从 软件 成 本 还 是 运 维 成 本 来 看 ，GoldenGate 都 是 不 适合 用 于 容 灾 的 ， 或 者 就 容 灾 来 阅 ，Data Guard 更 专业 、 更 简单 。 当 然 ， 这 都 是 基于 整 库 的 容 灾 ， 当 要 实现 数据 
库 部 分 数据 的 容 灾 呢 ? 或 者 说 是 实现 分 散 型 的 容 灾 ， 将 一 个 库 的 数据 分 散 到 多 个 容 灾 库 中 。 那 么 ，GoldenGate 容 灾 的 灵活 性 就 能 体现 出 来 了 。 


我 们 的 架构 设计 理念 就 是 “架构 让 系统 变 得 更 简单 ” ， 让 专业 产品 做 它 最 擅长 的 事情 。GoldenGate 最 擅长 的 就 是 做 准 实时 的 数据 复制 ， 即 使 是 容 灾 的 应 用 也 是 基于 这 个 功能 来 实现 的 。 因 此 ， 我 们 对 
GoldenGate 工 具 的 应 用 定位 应 该 是 实现 一 套 完整 的 准 实时 数据 集成 环境 。 


如 图 7-2 所 示 ， 通 过 GoldenGate 这 一 标准 化 的 单一 的 技术 解决 多 种 不 同 的 需求 ， 同 时 满足 系统 的 连续 可 用 性 ， 报 表 、BI 系 统 的 实时 数据 访问 的 要 求 ， 在 线 业务 系统 的 数据 分 发 和 负载 分 担 。 


QOracle 


异 构 数据 到 活动 备 库 
GoldenGate 


数据 分 发 


在 线 迁 移 与 升级 


容 灾 与 数据 保护 OLTP 应 用 


图 7-2 ” 准 实 时 数据 集成 应 用 
从 上 述 GoldenGate 构 建 的 数据 集成 平台 来 看 ，GoldenGate 在 整个 架构 中 主要 完成 了 以 下 两 件 事情 。 
“ 数据 的 集成 : 将 来 源 于 异 构 数据 库 环 境 的 数据 实时 地 集中 起 来 ， 形 成 一 个 统一 管理 的 数据 共享 平台 ; 


: 数据 的 分 发 : 将 集成 的 数据 按照 不 同 的 业务 要 求 ， 分 发 到 不 同 应 用 的 数据 库 ， 可 以 是 同 构 数据 库 环境 ， 也 可 以 是 异 构 环境 。 


与 其 他 数据 集成 工具 相 比 ，GoldenGate 架 构 的 集成 平台 ， 灵 活性 更 高 ， 实 时 性 更 强 ， 其 优势 主要 表现 在 以 下 几 个 方面 : 


“ 只 复制 业务 系统 的 关键 数据 表 ， 避 免 全 库 复 制 的 不 必要 开销 ; 

“ 可 以 实现 一 对 多 、 多 对 一 以 及 双向 数据 同步 ; 

“ 数据 的 同步 是 准 实时 的 ; 

“ 数据 同步 功能 支持 异 构 的 操作 系统 平台 、 数 据 库 平 台 (包括 同 产品 的 不 同 版 本 ) ; 


“ 数据 同步 的 架构 非常 灵活 ， 有 丰富 的 过 滤 及 转换 功能 。 


GoldenGate 之 所 以 能 提供 可 靠 的 数据 复制 ， 主 要 原因 包括 : 


“ 保证 事务 一 致 性 : GoldenGate 保 证 在 源 端 和 目标 端 进行 复制 的 过 程 中 ， 以 相同 的 顺序 进行 事务 提交 ， 确 保 在 目标 数据 库 上 的 数据 完整 性 和 读 一 致 性 。 


“ 检查 点 机 制 保障 无 数据 丢失 : GoldenGate 的 捕获 和 复制 进程 使 用 检查 点 机 制 记录 完成 复制 的 位 置 。 对 于 捕获 进程 ， 其 检查 点 记录 当前 已 经 捕获 日 志 的 位 置 和 写 跟踪 日 志文 件 的 位 置 ; 对 于 应 用 进程 ， 
其 检查 点 记录 当前 读 取 跟踪 日 志文 件 的 位 置 。 检 查 点 机 制 保证 在 系统 、 网 络 或 进程 故障 重启 后 数据 无 丢失 。 


:可靠 的 数据 传输 机 制 : GoldenGate 用 应 答 机 制 传输 交易 数据 ， 只 有 在 得 到 确认 消息 后 才 认 为 数据 传输 完成 ， 否 则 将 自动 重新 传输 数据 ， 从 而 保证 了 捕获 的 所 有 数据 都 能 发 送 到 目标 端 ， 且 传输 过 程 支 
持 128 位 加 密 和 数据 压缩 功能 。 


然而 ，GoldenGate 的 定位 为 中 间 件 层 的 数据 集成 工具 ， 虽 然 可 以 保证 事务 的 一 致 性 ， 但 是 ， 源 数据 库 和 目标 数据 库 是 分 布 式 的 两 个 独立 数据 库 ， 根 据 CAP 三 元 悖 论 ， 它 是 无 法 保证 实时 数据 的 一 致 性 
的 。 对 于 一 些 实时 要 求 比较 高 的 数据 库 应 用 ， 不 推荐 使 用 GoldenGate 来 同步 实时 交易 数据 ， 因 为 成 本 会 很 高 ， 而 且 不 容易 达到 预期 的 效果 。 


平台 是 死 的 ， 应 用 是 活 的 。GoldenGate 工 具 本 身 只 能 架构 出 一 套 准 实时 的 数据 集成 平台 ， 至 于 具体 的 应 用 场景 ， 关 键 取决 于 应 用 的 需求 。 基 于 小 核心 大 外 围 的 设计 思路 ， 还 是 比较 推荐 使 
GoldenGate 来 构建 数据 库 群 ， 解 决 高 并 发 的 问题 ， 集 中 表现 在 OLTP 的 数据 分 发 应 用 和 BI 分 析 的 应 用 ，GoldenGate 完 成 核心 和 外 围 之 间 的 数据 交互 。 


7.1.3 GoldenGate 技 术 架 构 


从 业务 支持 和 应 用 场景 来 看 ，GoldenGate 的 功能 是 非常 强大 的 ， 那 是 不 是 其 实现 的 技术 架构 很 复杂 呢 ? 恰恰 相反 ， 说 得 直 白 一 点 ，GoldenGate 的 实现 都 是 复制 链 路 的 实现 。 
1. 链 路 原理 


何 为 复制 链 路 呢 ? 简单 地 说 ， 就 是 有 一 个 源 数据 库 和 一 个 目标 数据 库 ， 在 两 者 之 间 建 立 数据 复制 关系 ， 那 么 一 条 复制 链 路 就 实现 了 。 当 出 现 多 个 源 数据 库 或 多 个 目标 数据 库 时 ， 就 需要 多 条 链 路 来 实现 
了 ， 单 条 链 路 上 有 上 且 仅 有 一 个 源 数据 库 和 一 个 目标 数据 库 。 如 图 7-3 所 示 为 一 条 完整 的 GoldenGate 复 制 链 路 的 实现 。 


数据 初始 化 


事务 日 志 


图 7-3 ”GoldenGate 链 路 原理 图 


在 一 条 完整 的 复制 链 路 中 ， 除 源 数据 库 和 目标 数据 库 之 外 ， 还 包含 以 下 几 个 组 件 : 
' 捕获 (Extract) 组 件 ; 

. 本 地 跟踪 (Local Trail) 日 志和 远程 跟踪 (Remote Trail) 日 志 ; 

. 数据 系 (Data Pump) 组 件 ; 

“应 用 (Replicat) 组 件 ; 


“ 监控 管理 (Manager) 组 件 。 


B。 


是 不 是 有 些 类 似 于 TimesTen 的 自动 刷新 功能 呢 ?” 当 然 ，GoldenGate 肯 定 要 做 得 更 完善 更 专业 的 。 那 么 ， 接 下 来 展开 看 一 下 复制 链 路 中 的 各 个 组 件 的 构成 和 作 | 


(1) 捕获 组 件 


捕获 (Extract) 组 件 的 主要 作用 是 通过 日 志 捕 获 进程 从 REDO 日 志 或 归档 日 志 中 获取 数据 库 的 变更 信息 ， 并 输出 到 本 地 跟踪 日 志文 件 。 在 默认 情况 下 ， 捕 获 进 程 会 从 REDO 日 志 中 获取 信息 ， 但 在 
Windows 平 台 下 ， 默 认 是 从 归档 日 志 中 获取 。 其 获取 的 信息 包括 : 


“主键 (或 唯一 键 ) 的 值 ; 


“ 变更 前 后 的 值 。 


因此 ， 需 要 复制 的 表 必 须 定 义 主键 ， 这 和 TimesTen 的 缓存 集合 是 一 样 的。 数据 库 并 不 要 求 是 归档 模式 ， 但 是 其 附加 日 志 模式 必须 打开 ， 保 证 主键 和 变更 值 信息 输出 到 REDO 日 志 。 


在 日 志 捕 获 过 程 中 ， 捕 获 进 程 将 会 以 一 定时 间 间 隔 ， 周 期 性 地 去 读 取 REDO 日 志 ， 间 隔 时 间 默 认为 1 秒 钟 一 次 ， 最 小 可 以 设置 为 10 毫 秒 一 次 ， 通 过 参数 FEOFDELAY 或 EOFDELAYCSECS 进 行 控制 。 


同时 ， 捕 获 进程 在 满足 一 定 条 件 时 ， 就 会 触发 其 到 本 地 跟踪 日 志文 件 的 输出 : 


“ 捕获 进程 的 缓冲 区 (内存 ) 写 满 ， 则 触发 跟踪 日 志 输出 ; 


“ 通过 设置 参数 FLUSHSECS 或 FLUSHCSECS 来 指定 触发 的 时 间 间 隔 ， 强 制 进行 跟踪 日 志 的 输出 ， 默 认为 1 秒 钟 一 次 ， 最 小 可 设置 为 10 毫 秒 一 次 。 


这 也 就 是 说 ， 通 过 GoldenGate 进 行 的 同步 复制 ， 其 极限 延 时 (不 计 跟 踪 日 志文 件 的 传输 和 应 用 ) 不 可 能 低 于 20 毫 秒 。 


在 双向 复制 的 应 用 场景 中 ， 为 了 避免 日 志 重 复 应 用 ， 造 成 死 循 环 ， 则 需要 设置 不 捕获 应 用 进程 (Replicat) 对 应 SQL 语句 所 产生 的 日 志 。 可 以 通过 捕获 进程 的 参数 来 设置 : 


“ GETAPPLOPS/IGNOREAPPLOPS: 指定 捕获 或 忽略 应 用 进程 以 外 的 进程 对 数据 库 的 更 新 操作 ; 
“ GETREPLICATES/IGNOREREPLICATES: 指定 捕获 或 忽略 应 用 进程 对 数据 库 的 更 新 操作 。 
(2) 跟踪 日 志 


跟踪 (Trail) 日 志文 件 就 是 将 数据 库 的 变更 信息 以 逻辑 形式 存储 起 来 的 GoldenGate 中 间 文 件 。 它 可 分 为 本 地 跟踪 日 志文 件 和 远程 跟踪 日 志文 件 ， 本 地 跟踪 日 志文 件 是 由 捕获 进程 直接 输出 的 ， 存 储 在 
源 端 数据 库 主 机 上 ， 其 通过 数据 泵 传输 到 目标 数据 库 端 ， 并 存储 在 目标 端 主机 上 ， 即 为 远程 跟踪 日 志文 件 。 两 者 的 本 质 都 是 一 样 的 ， 均 记录 的 是 源 数据 库 的 变更 信息 ， 并 准备 应 用 到 目标 数据 库 上 。 


(3) 数据 泵 组 件 


数据 泵 组 件 包 含 了 数据 泵 (Data Pump) 和 收集 器 (Collector) 两 部 分 ， 分别 用 于 在 源 端 和 目标 端 ， 发 送 和 接收 跟踪 日 志文 件 。 如 图 7-4 所 示 ， 数据 在 网 络 层 通 过 TCP/IP 协 议 传输 的 过 程 中 ， 是 可 以 进 
行 数据 压缩 的 ， 以 减轻 网 络 压力 。 


1 了 JEy 


图 7-4 跟踪 日 志 发 送 与 收集 


需要 注意 的 是 ， 在 日 志 传输 的 过 程 中 ， 我 们 也 可 以 不 设置 数据 泵 ， 直 接 由 捕获 进程 完成 日 志 传输 ， 这 样 是 不 会 记录 本 地 跟踪 日 志 的 。 图 7-5 所 示 为 两 种 日 志 传 输 的 方式 。 
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方法 二 


图 7-5 日 志 发 送 的 两 种 方式 


方法 一 : 启动 发 送 专用 的 数据 泵 ， 先 保存 到 本 地 跟踪 日 志文 件 ， 然 后 发 送 到 目标 端 。 这 种 方式 是 传统 的 方式 ， 也 是 值得 推荐 的 方式 。 


方法 二 : 捕获 组 件 兼顾 日 志 捕 获 和 发 送 之 职 从 REDO 日 志 取得 信息 ， 不 记录 本 地 跟踪 日 志 ， 直 接 向 目标 端 发 送 。 这 种 方式 看 似 简化 了 流程 ， 实 则 问题 不 小 ， 不 仅 增加 了 捕获 进程 的 负担 和 出 问题 的 概 
率 ， 而 且 因为 本 地 没有 跟踪 日 志 ， 对 后 续 可 能 的 问题 追溯 也 是 很 不 利 的 。 


因此 ， 我 们 推荐 使 用 方法 一 的 传统 发 送 方式 。 然 而 ， 当 面 对 一 对 多 的 复制 情况 时 ， 另 一 个 问题 也 随 之 出 现 了 : 是 为 每 一 条 链 路 单独 设置 日 志 发 送 用 的 数据 泵 ， 还 是 共享 数据 泵 呢 ? 如 图 7-6 所 示 ， 同 样 是 
面临 两 种 方式 的 选择 。 


方法 一 为 每 条 链 路 独立 设置 数据 泵 ， 方 法 二 为 共享 数据 泵 。 这 里 ， 我 们 还 是 推荐 方法 一 这 种 传统 配置 方式 。 因 为 共享 数据 泵 会 将 压力 和 风险 都 集中 在 共享 数据 泵 进程 上 ， 在 该 进程 负载 较 大 的 情况 下 ， 
如 果 出 现 单 点 故障 ， 势 必 影 响 整 个 应 用 。 


图 7-6 ”日志 多 目标 发 送 


远程 


日 志 


所 以 ， 我 们 需要 为 每 一 链 路 配置 独立 的 数据 泵 。 那 么 ， 是 否 有 必要 配置 独立 的 捕获 进程 呢 ? 这 就 属于 画蛇添足 了 。 因 为 捕获 进程 的 作用 仅 限于 输出 本 地 跟踪 日 志文 件 ， 它 并 不 实际 参与 日 志 发 送 与 接 


收 ， 如 果 配 置 过 多 捕获 进程 ， 反 而 会 增加 额外 的 磁盘 /O 开 销 。 


(4) 应 用 组 件 


应 用 (Replicat) 组 件 配置 在 目标 数据 库 端 ， 其 功能 为 从 远程 跟踪 日 志文 件 生成 SQL 语句 并 在 目标 数据 库 中 执行 ， 具 体 包括 : 


:以 变更 的 行为 单位 生成 SQL 语句 并 在 目标 数据 库 中 执行 ; 
“ 为 基于 主键 (或 唯一 键 ) 和 变更 前 的 值 (可 选 ) 更 新 (主键 或 唯一 键 的 值 是 在 源 端 通过 附加 日 志方 式 从 日 志 中 获得 ) 。 


(5) 监控 管理 组 件 


在 整 条 数据 复制 链 路 之 外 ， 其 实 还 有 一 个 监控 管理 (Manager) 组 件 在 进行 整合 控制 的 。 它 的 作用 包括 以 下 方面 。 
“ 跟踪 日 志文 件 的 管理 : 跟踪 日 志文 件 的 生成 和 删除 。 
“ 各 进程 的 监控 和 管理 。 


“ 定期 监控 进程 ， 例 如 进程 的 启动 、 停 止 、 再 启动 。 


“ 捕获 进程 、 应 用 进程 等 进程 的 状态 (如 处 理 完 的 检查 点 等 ) 都 会 保存 在 共享 内 存 中， 监控 管 理 进程 查询 共享 内 存 后 ， 可 以 产生 相关 报表 ， 显 示 各 进程 状态 。 


“ 目标 端的 监控 管理 进程 还 要 通过 TCP/IP 网 络 协议 与 源 端 的 数据 泵 进行 通信 ， 保 证 日 志 传输 正常 进行 。 
“ GoldenGate 整 体 的 监控 和 报表 。 


“ 执行 用 户 的 命令 : 用 户 可 以 通过 GGSCI 命 令 行 工具 和 GUI 图 形 化 管理 工具 与 监控 管理 组 件 进行 交互 ， 交 互 方式 同样 是 网 络 层 的 TCP/IP 协 议 。 


2. 单 向 链 路 


在 上 述 的 链 路 原理 中 ， 我 们 大 致 了 解 了 什么 是 数据 复制 链 路 ， 以 及 单条 链 路 的 实现 原理 。 那 么 对 于 单 向 链 路 来 说， 它 有 哪些 应 用 场景 呢 ， 或 者 说 我 们 如 何 去 使 


它 呢 ?当然 ， 这 里 需要 先 有 所 


向 链 路 并 不 是 单条 链 路 ， 它 可 以 有 多 个 源 端 和 多 个 目标 端的 ， 单 一 方向 复制 的 一 组 链 路 ， 且 在 这 一 组 链 路 中 ， 如 果 某 个 节点 成 为 源 节点 的 话 ， 那 么 它 将 不 可 以 同时 成 为 目标 节点 。 


如 图 7-7 所 示 ， 单 向 链 路 可 以 分 为 如 下 三 种 类 型 : 


“ 一 对 一 单 向 链 路 : 这 种 链 路 是 最 常用 的 一 种 链 路 ， 有 唯一 的 源 端 和 唯一 的 目标 端 ， 可 以 灵活 地 配置 多 种 应 用 场景 ， 比 如 容 灾 、 数 据 同步 等 。 


区 分 , 单 


“ 一 对 多 分 发 链 路 : 该 链 路 方式 多 用 于 单个 源 数据 库 到 多 个 目标 数据 库 的 数据 分 发 ， 前 面 说 到 的 小 核心 大 外 围 的 数据 库 群 架构 实现 就 可 以 通过 这 种 链 路 方式 来 完成 。 核 心 库 作为 源 数据 库 ， 其 中 包含 的 


核心 业务 数据 和 元 数据 作为 分 发 对 象 ， 按 需 分 发 到 各 个 外 围 目标 数据 库 中 。 


“ 多 对 一 集中 链 路 : 该 链 路 方式 中 ， 有 多 个 源 数据 库 和 一 个 目标 数据 库 ， 多 源 数 据 归 并 集中 到 单一 的 目标 数据 库 中 。 多 用 于 MIS 报 表 库 的 数据 采集 和 实时 BI 智 能 分 析 系统 的 支持 。 


小 


“对 多 分 发 链 路 多 对 一 集中 链 路 


图 7-7 单 向 链 路 部 署 因 


在 众多 GoldenGate 应 用 场景 的 链 路 搭建 和 配置 过 程 中 ， 我 们 应 该 尽 可 能 地 选择 单 向 链 路 ， 以 避免 双向 复制 可 能 造成 的 数据 冲突 ， 进 而 导致 数据 的 不 一 致 。 


3. 双 向 链 路 


双向 链 路 本 质 上 也 是 基于 上 述 的 链 路 原理 来 实现 的 ， 当 有 两 个 复制 节点 ， 彼 此 互 为 源 端 和 目标 端 时 ， 则 称 该 两 个 节点 之 间 建 立 了 双向 复制 链 路 。 


如 图 7-8 所 示 ， 现 有 两 套 应 用 系统 分 别 对 应 一 套数 据 库 ( 左 库 和 右 库 ) ， 在 其 间 搭建 了 从 左 到 右 和 从 右 到 左 两 条 数据 复制 链 路 ， 并 对 相同 数据 表 进 行 双向 复制 ， 则 双向 链 路 搭建 完成 。 这 里 为 了 便于 
分 ， 定 义 左 侧 的 为 源 数据 库 ， 右 侧 的 为 目标 数据 库 。 双 向 链 路 的 搭建 ， 实 际 上 就 成 功 地 将 两 套 系统 耦合 在 了 一 起 ， 并 互 为 备份 ， 也 可 以 称 为 双 活 系统 ， 它 实现 了 : 


一 


风 


“ 负载 均衡 ， 提 高 系统 整体 性 能 ; 


“ 连续 可 用 ， 快 速 的 容 灾 接 管 ; 


: 冲突 检测 和 处 理 。 


图 7-8 ”双向 链 路 的 应 用 


然而 ， 这 样 的 链 路 其 运 维 难度 往往 也 是 比较 大 的 。 在 如 下 的 场景 中 ， 我 们 尽 可 能 地 给 两 条 链 路 定义 一 下 Active 和 Standby 的 角色 (GoldenGate 不 支持 这 种 方式 的 定义 ， 只 是 人 工 的 定义 ) ， 即 只 允许 
Active 链 路 工作 ，Standby 链 路 为 关闭 状态 ， 当 业务 变化 或 故障 处 理 的 时 候 ， 进 行 角色 切换 。 这 样 的 做 法 有 些 类 似 于 Oracle 的 Data Guard， 也 能 实现 快速 恢复 和 切换 以 及 最 小 化 数据 损失 。 


纵 观 GoldenGate 的 技术 架构 ， 只 要 理解 了 链 路 的 实现 原理 ， 还 是 比较 容易 把 握 的 。 在 接 下 来 的 7.2 节 中 ， 我 们 将 展开 介绍 GoldenGate 工 具 的 具体 使 用 方法 。 


7.1.4 数据 库 群 的 制约 因素 


“小 核心 ,大 外 围 ” 的 数据 库 群 架 构 ， 数 据 库 森 林 体 系 的 关联 纽带 ， 这 些 都 少不了 GoldenGate 的 作用 。 然 而 ， 在 GoldenGate 强 大 功能 和 灵活 应 用 的 背后 ， 还 是 隐藏 了 相当 多 的 制约 因素 ， 对 于 一 些 特 
殊 要 求 的 应 用 场景 甚至 可 能 是 致命 的 。 


回顾 一 下 第 一 部 分 的 3.5.1 中 介绍 到 的 CAP 理 论 ， 分 布 式 体系 的 数据 库 设 计 中 ，CAP 三 要 素 形成 了 一 个 三 元 悖 论 ， 那 就 是 不 能 同时 满足 一 致 性 、 可 用 性 和 分 区 可 容忍 性 这 三 个 需求 ， 最 多 只 能 同时 满足 两 
个 ， 必 须 幅 牲 掉 另 一 个 。GoldenGate 搭 建 起 来 的 数据 库 群 ， 如 果 对 于 各 个 数据 库 都 只 是 单独 使 用 ， 那 么 一 点 问题 都 没有 ， 如 果 需 要 作为 一 个 数据 库 体系 来 使 用 就 必然 会 面临 CAP 理 论 的 制约 。 


使 用 GoldenGate 构 建 起 来 的 数据 库 群 实质 上 就 是 一 套 分 布 式 的 数据 库 体 系 ， 其 中 分 区 可 容忍 性 是 必须 要 保证 的 ， 而 当 两 个 数据 库 节点 间 存 在 实时 交易 数据 的 复制 时 ， 对 于 两 个 数据 库 来 说 ， 这 部 分 实 
时 交易 数据 都 是 要 求实 时 可 用 的 ， 那 么 在 两 者 之 间 的 数据 一 致 性 就 不 能 保证 了 。 很 不 幸 的 是 ， 这 部 分 数据 是 交易 数据 ， 牺 牲 掉 数 据 一 致 性 肯定 是 不 能 接受 的 。 对 于 这 样 的 情况 ，GoldenGate 变 得 不 适 
了 ,或 者 说 ， 仅 靠 中 间 件 层 和 数据 库 层 的 数据 集成 手段 是 不 容易 达到 的 。 当 出 现 跨 库 、 跨 应 用 的 实时 交易 数据 的 集成 时 ， 更 适合 使 用 应 用 集成 的 技术 ， 不 但 实时 性 高 ， 也 有 完善 的 高 可 用 机 制 。 


在 GoldenGate 的 分 布 式 数 据 库 群 体系 中 ， 我 们 可 以 保证 数据 一 致 性 和 分 区 可 容忍 性 ， 需 要 牺牲 掉 短 暂 的 可 用 性 。 也 就 是 说 在 GoldenGate 复 制 链 路 的 两 端 ， 不 能 都 是 实时 性 要 求 很 高 的 数据 ， 至 少 有 一 
端 是 允许 短暂 延 时 的 ， 也 正 是 我 们 前 面 说 到 的 GoldenGate 实 现 的 是 准 实时 复制 技术 。 


7.2 ”开始 使 用 


通过 7.1 节 的 应 用 场景 和 技术 架构 的 阐述 ， 我 们 对 GoldenGate 工 具 基 本 上 已 经 有 了 一 个 概念 性 的 了 解 ， 接 下 来 就 正式 进入 到 GoldenGate 的 数据 库 群 架构 的 搭建 中 。 


7.2.1 GoldenGate 安 装 


相 比 于 Oracle 和 TimesTen 来 说 ，GoldenGate 的 安装 过 程 应 该 算是 比较 简单 的 ， 在 本 例 中 ， 我 们 以 Linux 平 台 作为 实例 展示 。 


1.0S 用 户 与 组 创建 


使 用 操作 系统 root 用 户 创建 操作 系统 的 用 户 和 组 ， 用 户 名 为 ggalex， 组 名 为 oinstall， 作 为 GoldenGate 的 管理 和 操作 用 户 。 虽 然 GoldenGate 工 具 也 可 以 使 用 Oracle 的 安装 用 户 来 进行 操作 ， 但 是 为 了 
方便 区 分 与 管理 ， 还 是 需要 给 GoldenGate 工 具 创 建 独 立 的 管理 用 户 。 


# groupadd oinstall 
# groupadd dba 
# useradd -d /app/oracle/ggalex -g oinstall -G dba ggalex 


设置 用 户 ggalex 的 环境 变量 ， 启 用 ORACLE_SID=source 的 数据 库 与 GoldenGate 工 具 关 联 ， 使 之 作为 复制 链 路 的 源 数 据 库 (也 可 以 暂 不 配置 ) ， 修 改 .bash_profile 文 件 如 下 : 


export ORACLE SID=source 

export ORACLE BASE=/app/oracle/rdbms 

export ORACLF HOME=$ORACLE BASE/11g/11.2.0.3.2 

export TNS_ ADMIN=$ORACLE HOME/network/admin 

export GGS HOME=/app/oracle/ggalex/goldengate/source 

LD LIBRARY PATH=$GGS HOME/1ib:$ORACLE HOME/lib:$LD LIBRARY PATH 
export LD LIBRARY PATH 

export PATH=$GGS HOME:$ORACLE HOME/bin:$PATH:$HOME/bin 


2. 内 核 参 数 配 置 


通常 来 说 ，GoldenGate 工 具 和 Oracle 数 据 库 服 务 器 端 是 安装 在 同一 主机 上 的 ， 这 样 可 以 减少 额外 的 网 络 传输 开销 ， 而 GoldenGate 工 具 本 身 所 产生 的 系统 压力 是 非常 小 的 ， 不 必 担 心 对 数据 库 的 影响 ， 
因此 其 操作 系统 的 内 核 参 数 方面 完全 可 以 参照 Oracle 数 据 库 的 要 求 进行 配置 。 


3. 软 件 安装 


从 Oracle 官 网 下 载 GoldenGate 工 具 的 安装 介质 ， 并 保存 到 $GGS_HOME 路 径 下 ， 然 后 解压 缩 。GoldenGate 工 具 为 绿色 安装 软件 ， 解 压缩 后 即 可 直接 使 用 。 当 然 ， 在 使 用 前 还 需要 进行 一 些 必要 的 设 


步骤 1 创建 direoby 目 录 ， 用 于 保存 后 续 用 户 自 定义 的 oby 脚 本 文件 ， 通 过 这 些 脚本 文件 可 以 方便 地 配置 GoldenGate 的 进程 。 


$ cd SGGS_HOME 
$ mkdir diroby 


步 又 2 使 用 ggsci 命 令 进入 到 GoldenGate 的 管理 环境 (ggsci 为 一 款 类 似 于 sqlplus 的 命令 行 工 具 ) ， 并 执行 “create subdirs” 命令 ， 创 建 软件 相关 子 目 录 ， 用 于 GoldenGate 各 类 文件 的 保存 (具体 
作用 详 见 如 下 示例 ) 。 


$ ./ggsci 

Oracle GoldenGate Command Interpreter for Oracle 

Version 11.2.1.0.1 OGGCORE 11.2.1.0.1] PLATFORMS 120423.0230_ FBO 

Linux, x64, 64bit (optimized), Oracle 11g on Apr 23 2012 08:32:14 

Copyright (C) 1995, 2012, Oracle and/or its affiliates. All rights reserved. 
GGSCI (mysource) 1> create subdirs 

Creating subdirectories under /app/oracle/ggalex/goldengate/source 


Parameter files /app/oracle/ggalex/goldengate/source/dirprm: already exists 
Report files /app/oracle/ggalex/goldengate/source/dirrpt: created 
Checkpoint files /app/oracle/ggalex/goldengate/source/dirchk: created 
Process status files /app/oracle/ggalex/goldengate/source/dirpcs: created 
SQL script files /app/oracle/ggalex/goldengate/source/dirsql: created 
Database definitions files /app/oracle/ggalex/goldengate/source/dirdef: created 
Extract data files /app/oracle/ggalex/goldengate/source/dirdat: created 
Temporary files /app/oracle/ggalex/goldengate/source/dirtmp: created 


Stdout files /app/oracle/ggalex/goldengate/source/dirout: created 


至 此 ，GoldenGate 工 具 的 安装 就 已 经 完成 了 ， 是 不 是 非常 简单 ”但 是 ， 不 要 着 急 ， 因 为 后 续 的 配置 工作 就 比较 复杂 了 。 


值得 多 提 一 下 的 是 ， 对 于 单 台 主机 上 存在 多 个 数据 库 均 需 要 使 用 GoldenGate 工 具 进 行 数据 复制 的 情况 ， 建 议 给 每 个 数据 库 创 建 一 个 独立 GGS_HOME， 便 于 管理 和 后 续 问 题 的 追 洲 。 如 果 是 给 RAC 等 集 
群 环境 配置 GoldenGate， 那 么 GGS_HOME 需 要 建立 在 共享 存储 上 ， 以 便 实 现 故障 切换 ， 保 证 高 可 用 性 。 


7.2.2 GoldenGate 配 置 


下 面 我 们 就 展开 介绍 GoldenGate 使 用 的 配置 过 程 ， 还 是 以 Oracle 数 据 库 为 例 吧 。 看 看 如 何在 Oracle 同 构 的 环境 下 创建 一 个 简单 的 数据 复制 链 路 。 


1. 源 端 和 目标 端 数据 库 准备 


因为 在 本 例 中 ， 源 端 数据 库 和 目标 端 数据 库 都 是 Oracle， 其 环境 配置 准备 工作 也 是 一 样 的 ， 下 述 的 步骤 均 需 在 两 端 数据 库 上 进行 〈 单 向 链 路 中 ， 部 分 步骤 只 需 在 源 端 配置 ， 但 为 了 保证 数据 库 环境 配置 
的 一 致 性 ， 也 为 了 方便 双向 链 路 的 实现 ， 可 以 在 两 端 同样 配置 ， 但 需要 区 分 数据 库 的 SID) 。 


步骤 1 为 GoldenGate 工 具 创建 一 个 管理 用 户 ggalex， 并 根据 需求 做 好 该 用 户 的 最 小 化 权限 控制 。 同 时 ， 最 好 能 创建 一 个 独立 的 表 空间 供 其 使 


SQL> create User ggalex identified by ggalex 
2 default tablespace users 
3 temporary tablespace temp; 


步骤 2 打开 数据 库 的 附加 日 志 模 式 ， 便 于 GoldenGate 的 捕获 进程 从 REDO 日 志 获 取 完 整 的 准确 日 志 信 息 : 


SQL> alter database add supplemental log data; 
SQL> select supplemental 1og data min from v$database; 
SUPPLEMENTAL LOG DATA MIN 


步骤 3 ”对 于 10g 版 本 以 上 的 Oracle 数 据 库 还 需要 关闭 回收 站 功能 ， 示 例如 下 : 


SQL> alter system set recyclebin = off scope=spfile; 
SQL> select name,value from v$parameter2 where name like '%recyclebin%®'; 
NAME VALUE 


recyclebin off 


2. 源 端 和 目标 端 GoldenGate 配 置 


数据 库 的 配置 完成 之 后 ， 接 下 来 就 需要 在 GoldenGate 环 境 中 进行 连通 性 测试 和 监控 管理 进程 的 配置 了 。 


步骤 1 在 开始 配置 之 前 ， 需 要 先 给 GoldenGate 环 境 创建 一 个 检查 点 表 。 在 默认 情况 下 ，GoldenGate 的 检查 点 信息 保存 在 “$GGS_HOME\dirchk” 路 径 下 的 文件 中 ， 这 样 不 便于 管理 与 查看 。 比 较 好 
的 做 法 是 ， 创 建 一 个 Oracle 的 表 用 于 保存 检查 点 信息 ， 示 例如 下 : 


@ 配 置 GoldenGate 全 局 环境 变量 ， 添 加 检查 点 配置 信息 : 


$ ./ggsci 
GGSCI (mysource) 1> edit params ./GLOBALS 


@ 输 入 以 下 内 容 : 


CHECKPOINTTABLE ggalex.t checkpoint 
syslog none 


@ 在 GGSCI 环 境 中 连接 到 Oracle 数 据 库 : 


GGSCI (mysource) 2> dblogin userid ggalex, password ggalex 
Successfully logged into database. 


@ 在 Oracle 数 据 库 中 创建 检查 点 表 : 


GGSCI (mysource) 3> add checkpointtable ggalex.t checkpoint 
Successfully created checkpoint table ggalex.t checkpoint. 


步骤 2 此 步骤 为 给 GoldenGate 进 行 加密 控 制 ， 不 是 必须 的 ， 但 建议 还 是 尽 可 能 地 配置 一 下 。 先 进 到 $GGS_HOME 目 录 ， 通 过 keygen 命 令 生成 一 组 128 位 的 加 密 密 钥 ， 并 给 该 密 钥 取 名 为 “mykey”， 
并 将 配置 信息 写 入 ENCKEYS 文 件 中 ， 示 例如 下 : 


$ cd $GGS HOME 

$ keygen 128 1 

0x250F8B74461D404F6CB0D33DE1D96940 

$ echo "mykey 0x250F8B74461D404F6CB0D33DE1D96940" > ENCKEYS 


进入 GGSCI 环 境 ， 通 过 密 钥 mykey 对 ggalex 用 户 的 密码 进行 加 密 处 理 ， 获 取 并 记录 密码 的 加 密 字符 捉 信息 ， 如 下 所 示 : 


$ ./ggsci 

GGSCI (mysource) 1> encrypt password ggalex encryptkey mykey 
Encrypted password: AADAAAAAAAAAAAG.....SF 

Algorithm used: AES128 


步骤 3 在 $GGS_ HOME/diroby 路 径 下 ， 生 成 全 局 调用 oby 脚 本 文件 env.oby 用 于 Oracle 数 据 库 的 连接 (如 果 配 置 了 AES128 加 密 ， 则 需要 配置 好 加 密 信息 ) ， 并 配置 Oracle 数 据 库 的 SID 信 息 ， 示 例如 


$ cd $GGS HOME/diroby 
$ echo "SETENV (ORACLE SID = \"source\")" > env.oby 
$ echo "userid ggalex, password AADAA....SF, encryptkey mykey" >> env.oby 


步骤 4 ” 接 下 来 就 可 以 开始 配置 监控 管理 进程 了 。 进 入 $GGS_HOME/dirprm 目 录 ,该 目录 下 保存 的 prm 文 件 为 各 个 GoldenGate 进 程 的 配置 文件 。 这 里 ， 我 们 需要 创建 一 个 “mgr.prm” 文 件 用 于 配 


监控 管理 进程 。 当 然 ， 我 们 完全 可 以 在 GGSCI 环 境 中 ， 通 过 命令 行 来 逐 行 配置 ， 但 是 通过 配置 文件 来 配置 的 方式 更 便于 管理 。 具 体 参数 配置 和 说 明示 例如 下 : 


$ cat > $GGS_HOME/dirprm/mgr.prm <<EOF 
PORT 7809 

SYSLOG NONE 

DYNAMICPORTLIST 7809-7850,7860 

AUTOSTART ER * 

AUTORESTART ER *, RETRIES 4, WAITMINUTES 4 

PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 2 
EOF 


上 例 中 ，mgr 进 程 各 项 参数 的 配置 说 明 详 如 表 7-2 所 示 。 


表 7-2 ”mgr 进程 配置 参数 说 明 


参 数 说 明 


PORT mgr 进程 的 端口 号 

SYSLOG NONE 禁止 GoldenGate 的 消息 写 人 系统 日 志 
DYNAMICPORTLIST 用 于 传输 跟踪 日 志文 件 的 动态 断口 列表 
AUTOSTART 当 mgr 进程 启动 时 ， 其 他 进程 自动 随 mgr 进程 启动 
AUTORESTART 当 mgr 进程 重启 时 ， 其 他 进程 自动 随 mgr 进程 重启 
PURGEOLDEXTRACTS 设置 过 期 的 跟踪 日 志文 件 的 自动 清理 


步骤 5 mgr.prm 配 置 完成 之 后 ， 就 可 以 去 启动 监控 管理 进程 ， 并 查看 其 运行 状态 ， 确 认 配 置信 息 生效 且 正 常 运行 ， 具 体 示例 如 下 : 


GGSCI (mysource) 1> start mgr 

GGSCI (mysource) 2> info all 

Program Status Group Lag at Chkpt Time Since Chkpt 
MANAGER RUNNING 


上 述 例子 中 ，Group 表 示 进 程 的 名 称 (mgr 进 程 不 显示 ) ，Lag 表 示 进 程 的 延 时 ，Status 表 示 进 程 的 状态 ， 其 包含 如 下 四 种 状态 : 
“ STARTING: 进程 正在 启动 过 程 中 

“ RUNNING: 进程 正常 运行 

“ STOPPED: 进程 被 正常 关闭 

: ABENDED: 进程 非 正 常 关闭 ， 需 要 进一步 调查 原因 


对 于 mgr 进 程 参数 配置 情况 ， 可 以 通过 如 下 方式 查看 : 


GGSCI (mysource) 3> view params mgr 

PORT 7809 

SYSLOG NONE 

DYNAMICPORTLIST 7809-7850 

AUTOSTART ER * 

AUTORESTART ER *, RETRIES 4, WAITMINUTES 4 

PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 2 


至 此 ，GoldenGate 环 境 的 基础 配置 工作 ， 我 们 就 已 经 完成 了 ， 可 以 基于 这 个 环境 去 进行 具体 链 路 的 配置 了 。 


7.2.3 ”基本 链 路 的 搭建 


下 面 我 们 就 展开 介绍 GoldenGate 最 基本 的 单 向 链 路 的 搭建 过 程 。 在 正式 开始 之 前 ， 需 要 先 明确 一 个 比较 重要 的 问题 ， 就 是 数据 库 的 SCN 的 把 握 。 我 们 知道 对 于 任何 一 个 在 线 的 数据 库 来 说 ， 我 们 都 会 
面临 以 下 两 个 问题 : 


“ 不 大 可 能 为 了 创建 一 条 GoldenGate 链 路 而 停机 ， 这 需要 把 握 好 数据 库 的 SCN 号 ; 


“ 不 大 可 能 会 只 为 空 表 来 创建 链 路 ， 在 保证 SCN 号 的 同时 在 线 完成 数据 初始 化 迁移 。 


这 在 一 定 程度 上 增加 了 操作 的 难度 ， 更 显示 出 SCN 号 的 意义 。 如 图 7-9 所 示 ， 是 基本 链 路 搭建 的 具体 步骤 展示 : 


步骤 1 安装 GoldenGate 的 环境 ， 并 配置 好 mgr 进 程 ， 这 一 步骤 在 7.2.2 节 已 经 完成 。 


步骤 2 在 源 端 节点 配置 好 捕获 进程 和 数据 泵 进程 。 


步骤 3 ”在 源 端 节点 立刻 开启 捕获 进程 和 数据 泵 进程 ， 此 时 即 可 开启 对 数据 库 日 志 的 捕获 并 记录 到 GoldenGate 的 跟踪 日 志文 件 中 。 需 要 注意 的 是 ， 捕 获 时 点 必须 在 数据 初始 化 时 点 之 前 ， 保 证 能 覆盖 到 


exp/imp 的 SCN。 


步骤 4 ”此 时 源 端 的 数据 泵 进程 已 经 与 目标 端的 mgr 进 程 建立 了 连接 ， 跟 踪 日 志文 件 也 应 该 能 成 功 传输 到 目标 端 ， 确 认 完 成 后 再 进行 目标 端 应 用 进程 的 配置 。 


步骤 5 ”检查 源 库 的 事务 运行 情况 ， 并 记录 下 数据 库 此 时 的 SCN。 


步骤 6 根据 步骤 5 中 记录 的 SCN 号 ， 导 出 需要 同步 的 数据 表 ， 并 将 DUMP 文 件 传输 到 目标 端 。 


步骤 7 在 目标 端 导 入 数据 表 到 目标 数据 库 中 。 


步骤 8 ”根据 步骤 5 中 记录 的 SCN 号 ， 启 用 应 用 进程 ， 应 用 进程 开始 应 用 SCN 号 之 后 的 数据 库 变更 到 目标 库 ， 链 路 搭建 完成 。 


QO 配置 环境 


@ 按 SCN 号 ， 导 出 数据 QD 导入 数据 
an Tp 
1 


检查 源 库 v $ transaction 的 min (start time) ， 


并 记录 当前 数据 库 的 SCN 


到 捕获 讲 程 和 煞 握 硒 


和 @ 根 据 记录 的 SCN 号 ， 启 动 应 用 进程 


图 7-9 ”基本 链 路 的 搭建 


了 解 了 链 路 搭建 的 基本 步骤 和 思路 ， 我 们 就 按照 上 述 步骤 展开 一 个 具体 的 搭建 实例 ， 更 为 直观 地 体会 链 路 的 搭建 过 程 。 


1. 源 数据 库 的 测试 表 准备 


在 源 数据 库 (source 库 ) 上 创建 两 个 测试 用 表 alex.t_ggs_701 和 alex.ggs_test， 并 分 别 为 两 个 表 进 行 数据 的 初始 化 。SQL 语 句 如 下 所 示 : 


SQL> create table alex.t ggs 701 (id number primary key, 
2 name varchar(10)); 
SQL> create table alex.ggs test (id number primary key, cur time date, 
2 source varchar2(10), target varchar2 (10)); 
SQL> begin 
2 for i in lhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/..10000 loop 
3 insert into alex.t ggs 701 values (i,'alex'); 
4 end loop; IE 
5 


6 end; 


SQL> insert into alex.ggs test values (1l, sysdate, "Source'， 'target'); 
SQL> commit; 


2. 配 置 捕 获 进程 和 数据 泵 进程 


在 开始 进程 配置 之 前 ， 我 们 需要 先 来 配置 三 个 文件 ， 用 于 进程 的 控制 ， 当 然 也 可 以 在 GGSCI 环 境 通 过 命令 行 来 配置 ， 但 是 使 用 配置 文件 更 为 方便 ， 具 体 说 明和 步骤 如 下 所 示 。 


(1) 操作 说 明 


e_source.prm: 预备 创建 一 个 名 为 e source 的 捕获 进程 ， 用 于 捕获 数据 库 日 志 到 跟踪 日 志文 件 。 通 过 exttrail 参 数 指定 本 地 跟踪 日 志文 件 的 保存 路 径 和 文件 前 缀 ， 以 及 table 参 数 指定 捕获 目标 表 为 
alex.t ggs_ 701 和 alex.ggs_test。 


d source target.prm: 预备 配置 一 个 名 为 d_ target 的 捕获 进程 ， 用 于 传输 跟踪 日 志 ， 为 了 便于 区 分 ， 称 其 为 数据 泵 进程 。 通 过 rmthost 参 数 指定 目标 端 主机 地 址 和 mgr 进 程 端口 ， 以 及 rmttrail 参 数 指 
定 远程 跟踪 日 志 的 保存 路 径 和 文件 前 级 ， 同 时 也 需要 指明 捕获 的 目标 表 。 


source.prm: GoldenGate 同 步 的 目标 端 在 应 用 日 志 时 ， 是 无 法 自动 识别 日 志 对 应 数据 格式 的 ， 需 要 在 源 端 生成 一 个 定义 def) 文件， 包含 待 同步 表 和 字段 的 定义 ， 并 手工 传输 到 目标 端 对 应 位 置 保 
存 。 该 文件 就 是 用 于 定义 文件 生成 过 程 的 配置 。 


(2) 操作 步骤 


步骤 1 捕获 进程 配置 文件 : 


$ cat > $GGS HOME/dirprm/e_source.prm <<EOF 
extract e source 

obey ./diroby/env.oby 

exttrail ./dirdat/e0 

table alex.t ggs_ 701; 

table alex.ggs test; 

EOF 站 


步骤 2 数据 泵 进程 配置 文件 : 


$ cat > $GGS HOME/dirprm/d source target.prm <<EOF 
extract d target 

obey ./diroby/env.oby 

rmthost mytarget, mgrport 8809 

rmttrail ./dirdat/dl 

table alex.t ggs 701; 

table alex.ggs test; 

EOF 


步骤 3 生成 def 文 件 配置 文件 : 


$ cat > $GGS HOME/dirprm/source.prm <<EOF 

defsfile ./dirdef/source.def, purge 

userid ggalex, password AADAAAAAAAAAAAGAU....EJBOESF, encryptkey mykey 
table alex.t ggs_701; 

table alex.ggs test; 

EOF 


3. 开 启 捕获 进程 和 数据 泵 


完成 了 进程 配置 的 编辑 并 不 意味 着 完成 了 GoldenGate 进 程 的 配置 ， 此 时 mgr 进 程 还 是 无 法 识别 到 捕获 进程 和 数据 泵 进程 的 。 需 要 在 GGSCI 环 境 中 ， 添 加 e_source 和 d_target 进 程 并 启用 。 示 例如 下 : 


@ 源 端 添加 待 同步 表 的 附加 日 志 : 


GGSCI (mysource) 1> dblogin userid ggalex, password ggalex 
Successfully logged into database. 

GGSCI (mysource) 2> add trandata alex.t ggs_701 

Logging of supplemental redo data enabled for table ALEX.T GGS 701. 
GGSCI (mysource) 3> add trandata alex.ggs test 村 
Logging of supplemental redo data enabled for table ALEX.GGS TEST. 


@ 源 端 添加 捕获 进程 服务 并 启 


GGSCI (mysource) 4> add extract e source, tranlog, begin now 
EXTRACT added. 

GGSCI (mysource) 5> add exttrail ./dirdat/e0, extract e source 
EXTTRAIL added. 
GGSCI (mysource) 6> start e source 


Sending START request to MANAGER http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/OEBPS/Text/... 


EXTRACT E SOURCE starting 


@ 源 端 添加 数据 泵 进程 服务 并 启 


GGSCI (mysource) 7> add extract d target, exttrailsource ./dirdat/e0, 
params ./dirprm/d source target.prm 

EXTRACT added. 

GGSCI (mysource) 8> add rmttrail ./dirdat/dl, extract d target 

RMTTRAIL added. 

GGSCI (mysource) 9> start d target 


Sending START request to MANAGER http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/O0EBPS/Text/... 


EXTRACT D TARGET starting 


成 功 添加 并 启用 后 ,数据 泵 进程 就 可 以 与 目标 端的 mgr 进 程 建立 通信 ， 并 将 本 地 跟踪 日 志文 件 传输 到 目标 端 主机 。 


同时 ， 在 源 端 主机 上 根据 source.prm 配 置 文件 ， 生 成 定义 文件 source.def 到 dirdef 子 目录 ， 并 传输 到 目标 端 主机 上 的 对 应 位 置 ， 操 作 如 下 所 示 : 


$ cd $GGS_ HOME 
$ ./defgen paramfile dirprm/source.prm 
$ scp dirdef/source.def ggalex@mytarget:$GGS HOME/dirdef 


4. 配 置 应 用 进程 


接 下 来 转 到 目标 端 进行 应 用 进程 的 配置 吧 。 应 用 进程 配置 文件 r_source_target.prm， 其 内 容 相 对 于 捕获 进程 和 数据 泵 进程 较为 复杂 。 通 过 replicat 参 数 指定 进程 名 ，sourcedefs 参 数 


置 ， 以 及 map 参 数 来 对 应 好 链 路 的 源 端 和 目标 端 表 和 字段 的 对 应 关系 。 如 下 所 示 : 


$ cat > r source target.prm <<EOF 

replicat r source 

obey ./diroby/env.oby 

sourcedefs ./dirdef/source.def 

discardfile ./dirrpt/r_source.dsc, append 
map alex.t ggs 701 , target alex.t ggs 701, & 
colmap ( rv 

id = id ， 

name = name 

) 7 

map alex.ggs test , target alex.ggs test, & 
colmap ( 

id = id ， 

cur time = cur time ， 

source = source ， 

target = target 

) 7 

EO 


Co 


日 三 丰 . 


义 文件 的 位 


上 例 中 ， 同 步 的 表 和 字段 都 是 同 构 的 ， 如 果 出 现 异 构 的 情况 ， 需 要 在 map 参 数 中 做 好 关系 对 应 。 这 种 异 构 的 转换 通常 推荐 在 目标 端 进行 ， 因 为 相对 于 源 端 来 说 ， 目 标 端的 压力 会 更 小 一 些 。 然 而 ， 仍 需 


要 注意 的 是 ， 虽 然 源 和 目标 的 表 名 和 字段 名 可 以 不 同 ， 但 是 字段 类 型 和 长 度 最 好 保持 一 致 ， 以 免 出 现 不 必要 的 数据 丢失 。 


同样 ， 需 要 GoldenGate 识 别 应 用 进程 的 配置 ， 需 要 在 GGSCI 环 境 中 如 下 添加 : 


GGSCI (mytarget) 1> add replicat r source, exttrail ./dirdat/dl， 
params ./dirprm/ r source target.prm 
REPLICAT added. 


5. 获 取 源 数据 库 SCN 


获取 源 数据 库 的 SCN 号 应 该 算是 最 关键 的 一 步 了 ， 因 为 在 目标 端 应 用 进程 应 用 跟踪 日 志 时 会 根据 这 个 时 间 点 做 判断 ， 如 果 应 用 日 志 的 时 间 早 于 该 时 点 ， 可 能 导 
于 该 时 点 ， 则 可 能 导致 数据 丢失 。 


如 下 例 所 示 ， 需 要 先 记录 一 下 在 当前 的 源 数据 库 的 SCN 号 : 


SQL> select min(start time) from VS$Stransactiony 

MIN (START_TIME) 

SQL> select dbms flashback.get system change number from dual; 
GET_SYSTEM CHANGE NUMBER 


16382124 


致 


日 志 征 


复 应 上 


， 如 果 应 有 


志 的 时 间 晚 


6 .导出 数据 


根据 上 述 步骤 获取 的 SCN 号 ， 在 exp 过 程 指定 flashback_scan 参 数 进行 待 同 步 表 的 导出 ， 并 将 导出 的 DUMP 文 件 传输 到 目标 端 主机 上 ， 示 例如 下 : 


$ exp alex/alex file=exp source.dmp log=exp_source.1og 
tables=\ (alex.t_ggs_701,alex.ggs_test\) flashback scn=16382124 


7. 导 入 数据 


在 目标 数据 库 导 入 DUMP 备 份 文件 ， 此 时 在 目标 数据 库 的 待 同步 表 alex.t_ggs_ 701 和 alex.ggs test 的 数据 时 间 点 相当 于 源 数据 库 的 SCN=16382124 的 时 间 点 ， 两 个 库 的 待 同步 表 数 据 是 不 一 致 的， 目标 
库 要 滞后 于 源 库 。 


$ imp alex/alex file=exp_source.dmp fromuser=alex touser=alex 


8. 启 用 应 用 进程 


虽然 说 目标 库 的 时 间 点 滞后 了 ， 但 是 不 必 担 心 ， 因 为 GoldenGate 的 捕获 进程 在 源 数 据 库 的 SCN=16382124 时 间 点 之 前 就 已 经 启动 了 ， 也 就 是 说 GoldenGate 的 跟踪 日 志 能 够 完全 覆盖 到 该 时 间 点 以 后 
的 所 有 源 库 上 待 同步 表 的 变更 。 


此 时 ， 我 们 就 可 以 启动 目标 端的 应 用 进程 了 。 特 别 注意 的 是 ， 在 启动 的 时 候 需要 添加 aftercsn 参 数 ， 来 指定 日 志 开 始 应 用 的 时 间 点 (aftercsn 参 数 对 应 的 是 源 数据 库 的 SCN 号 ， 下 例 中 为 
SCN=16382124) 。 操 作 示例 如 下 : 


GGSCI (mytarget) 1> start r source aftercsn 16382124 
Sending START request to MANAGFR http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/... 
REPLICAT R SOURCE starting 


至 此 ， 我 们 就 完成 了 一 条 链 路 的 搭建 ， 如 果 要 进行 双向 链 路 、 环 形 链 路 等 复杂 链 路 的 搭建 ， 原 理 和 上 述 步骤 是 一 样 的 。 然 而 ， 值 得 注意 的 是 ， 当 出 现 集中 式 复制 (多 源 一 目标 ) 时 ， 需 要 为 每 个 源 端 到 
目标 端的 复制 搭建 独立 链 路 。 而 当 出 现 分 发 式 复制 (一 源 多 目标 ) 时 ， 源 端的 捕获 进程 只 需要 配置 一 个 即 可 ， 因 为 源 端的 跟踪 日 志文 件 是 可 以 共享 的 ， 但 是 数据 泵 进程 和 应 用 进程 仍 需要 独立 开 来 。 


7.2.4 GoldenGate 的 监控 


GoldenGate 在 监控 方面 ， 可 以 说 做 到 了 跟 Oracle 数 据 库 一 样 ， 也 是 非常 完善 的 。 在 Oracle 数 据 库 的 监控 方面 ， 通 常 可 以 使 用 SQLPLUS 命 令 工具 和 OEM 图 形 化 工具 这 两 种 官方 工具 来 进行 数据 库 状态 的 
监控 。 而 在 GoldenGate 中 ， 同 样 有 以 下 两 种 工具 : 


“ GGSCI 命 令 工具 : 这 款 工具 在 本 章 中 已 经 多 次 提 到 ， 它 和 SQLPLUS 一 样 ， 可 以 通过 命令 行 来 进行 必要 的 查询 和 操作 ， 对 于 经 验 丰富 的 DBA 老 手 ， 更 愿意 选择 该 类 工具 。 而 有 全， 可 以 自 定义 一 些 监控 脚 
本 和 工具 ， 来 调用 GGSCI 的 命令 接口 ， 自 动 生 成 监控 报告 ， 其 灵活 性 易于 把 握 。GGSCI 命 令 行 返回 的 信息 包括 : 整体 概况 、 进 程 运行 状态 、 检 查 点 信息 、 参 数 文件 配置 、 延 时 等 。 


' GoldenGate Director 图 形 化 工具 : 它 是 一 款 类 似 于 OEM 的 图 形 化 工具 ， 可 以 通过 远程 客户 端 来 配置 和 管理 GoldenGate 实 例 ， 功 能 强大 ， 所 见 即 所 得 ， 对 于 DBA 新 手 是 一 个 不 错 的 选择 ， 当 然 也 可 以 给 


DBA 老 手提 高 工作 效率 。 如 果 GoldenGate 是 大 规模 的 部 署 ， 而且 架构 比较 复杂 ， 则 该 工具 值得 推荐 。 


下 面 我 们 将 主要 围绕 GGSCI 展 开 介 绍 GoldenGate 相 关 的 监控 


1.info 命 令 


先 来 看 看 最 为 常用 的 info 命 令 吧 ， 当 进入 到 GGSCI 环 境 ， 键 入 “info all” 命 令 ， 可 以 查看 当前 GoldenGate 节 点 的 整体 运行 状况 ， 包 括 : 进程 组 名 (Group) 、 类 型 (Program) 、 运 行 状态 
(Status) ， 以 及 检查 点 和 延 时 信息 (进程 状态 说 明 参 见 7.2.2 节 中 的 介绍 ) 。 该 命令 执行 结果 如 下 所 示 : 


GGSCI (mysource) 1> info al1 


Program Status Group Lag at Chkpt Time Since Chkpt 
MANAGER RUNNING 

EXTRACT RUNNING D TARGET 00:00:00 00:00:09 
EXTRACT RUNNING E_SOURCE 00:00:00 00:00:05 


如 果 需 要 查看 指定 进程 (比如 : E_SOURCE) 的 运行 状态 ， 则 可 以 通过 “info e_source” 命令 来 查询 ， 查 询 结果 如 下 所 示 ， 包 含 了 更 多 更 为 详细 的 状态 信息 : 


GGSCI (mysource) 2> info e source 
EXTRACT E_SOURCE Last Started 2013-06-15 14:50 Status RUNNING 
Checkpoint Lag 00:00:00 (updated 00:00:04 ago) 
Log Read Checkpoint Oracle Redo Logs 
2013-06-16 11:33:03 Seqno 413, RBA 25385472 
SCN 0.16555366 (16555366) 


是 否 觉得 以 上 信息 还 不 够 详细 ， 不 足以 满足 监控 所 需 呢 ?没有 关系 ,我 们 还 可 以 再 详细 一 些 。 在 上 述 命令 之 后 加 上 一 个 “detail” 关 键 词 ， 就 可 以 获取 最 为 完整 的 状态 信息 ， 结 果 如 下 所 示 : 


GGSCI (mysource) 3> info e source detail 
EXTRACT 也 SOURCE Last Started 2013-06-15 14:50 Status RUNNING 
Checkpoint Lag 00:00:00 (updated 00:00:05 ago) 
Log Read Checkpoint Oracle Redo Logs 
2013-06-16 11:41:23 Seqno 413, RBA 25701376 
SCN 0.16556394 (16556394) 
Target Extract Trails: 


Remote Trail Name Seqno REA Max MB 

./dirdat/e0 0 T2719 100 

Extract Source Begin End 

/redo/redo02.10g 2013-06-15 14:41 2013-06-16 11:41 

Not Available * Initialized * 2013-06-15 14:41 
Current directory /app/oracle/ggalex/goldengate/source 
Report file /app/oracle/ggalex/goldengate/source/dirrpt/E SOURCE.rpt 
Parameter file /app/oracle/ggalex/goldengate/source/dirprm/e_source.prm 
Checkpoint file /app/oracle/ggalex/goldengate/source/dirchk/E_ SOURCE .cpe 
Process file /app/oracle/ggalex/goldengate/source/dirpcs/E_SOURCE .pce 
Stdout file /app/oracle/ggalex/goldengate/source/dirout/E SOURCE.out 
Error log /app/oracle/ggalex/goldengate/source/ggserr.10g 


上 例 中 的 ggserr.log 对 于 GoldenGate 的 监控 来 说 ， 是 一 个 非常 重要 的 文件 ， 它 相当 于 Oracle 数 据 库 的 alert.log 文 件 ， 记 录 了 GoldenGate 的 各 类 报错 信息 ， 对 于 排 错 分 析 有 着 重要 的 意义 。 


如 果 需 要 查询 具体 的 检查 点 信息 和 GoldenGate 进 程 处 理 过 的 事务 记录 ， 也 可 以 使 用 “info< 进 程 名 称 >showch” 命令 来 查询 ， 比 如 需要 查询 e source 进程 的 检查 点 详细 信息 ， 可 以 如 下 进行 查询 : 


GGSCI (mysource) 4> info e_source showch 


2.lag 命 令 


如 果 GoldenGate 的 某 个 进程 在 复制 过 程 中 出 现 延 时 ， 那 么 我 们 称 之 为 出 现 了 “LAG”。 进 程 的 “LAG” 情 况 是 需要 严密 监控 的 。 在 GGSCI 命 令 中 ， 可 以 通过 “lag< 进 程 名 称 >” 命 令 查 看 详细 的 延 时 信 
息 ， 比 如 要 查看 e_source 进 程 延 时 情况 ， 可 以 如 下 查询 : 


GGSCI (mysource) 5> lag e source 

Sending GETLAG request to EXTRACT E SOURCE http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/... 
Last record lag: 2 seconds. 

At EOF, no more records to process. 


3.stats 命 令 


“stats” 命 令 也 是 作用 于 各 个 进程 的 ， 它 可 以 用 来 查看 各 进程 处 理 过 的 记录 数 。 通 过 对 比 捕获 进程 、 数 据 泵 进程 和 应 用 进程 的 记录 处 理 数 ， 也 能 监控 到 进程 是 否 出 现 阻 塞 。 比 如 要 查看 捕获 进程 
e_source 的 处 理 情况 的 汇总 (需要 查询 明细 则 不 需要 “total” 关 键 词 ) 可 以 如 下 查询 : 


GGSCI (mysource) 6> stats e source, total 


通常 来 说 ，“stats” 命 令 获取 到 的 信息 会 比较 多 ,我们 也 可 以 添加 一 些 谓词 来 进行 查询 的 筛选 。 比 如 ， 需 要 查询 表 alex.t_ggs_701 当 天 的 处 理 信息 ， 可 以 进行 如 下 查询 : 


GGSCI (mysource) 7> stats e source, daily, table alex.t ggs 701 

Sending STATS request to EXTRACT E SOURCE http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/14941/0EBPS/Text/... 
Start of Statistics at 2013-06-16 15:30:34. 

Output to ./dirdat/e0: 

Extracting from ALEX.T GGS 701 to ALEX.T GGS 701: 

**#** Daily statistics since 2013-06-16 00:00:00 *** 


Total inserts 1.00 
Total updates 0.00 
Total deletes 0.00 
Total discards 0.00 
Total operations 1.00 


End of Statistics. 


“stats” 命 令 在 进程 问题 的 诊断 方面 有 着 非常 重要 的 作用 ， 链 路 上 数据 同步 的 记录 处 理 状态 也 是 GoldenGate 监 控 工作 中 不 可 或 缺 的 一 部 分 。 


4.view 命 令 


“view” 命令 更 像 是 一 个 查看 进程 配置 和 生成 进程 报告 的 工具 ， 如 果 要 查看 mgr 进 程 的 参数 配置 情况 ， 可 以 进行 如 下 查询 : 


GGSCI (mysource) 8> view param mgr 


而 要 获取 该 进程 的 完整 报告 ， 则 需要 执行 下 述 命令 : 


GGSCI (mysource) 9> view report mgr 


当然 要 查看 最 新 的 进程 报告 ， 也 可 以 直接 到 $GGS_HOME/dirrpt 子 目录 下 进行 相关 文件 查询 。 报 告 文件 是 以 进程 名 为 前 缀 的 rpt 格 式 文件 。 示 例如 下 : 


$ 11 MGR* 
-rw-rw-rw- 1 ggalex oinstall 2243 Jun 15 11:27 MGRO.rpt 
—rw-rw-rw- 1 ggalex oinstall 2107 Jun 12 17:42 MGR1.rpt 


Trw-rw-rw- 1 ggalex oinstall 2762 Jun 15 14:52 MGR.rpt 


GoldenGate 虽 然 不 是 一 套数 据 库 软件 ， 而 是 一 款 中 间 件 工具 ， 但 是 对 于 使 用 GoldenGate 架 构 起 来 的 数据 库 群体 系 来 说 ，GoldenGate 的 监控 工作 的 重要 性 毫 不 亚 于 数据 库 本 身 。 因 为 其 建立 的 数据 库 
群 实质 上 就 是 一 套 分 布 式 数据 库 体 系 ，GoldenGate 出 现任 何 问题 都 可 能 导致 严重 的 数据 不 一 致 。 


7.3 ”高 级 应 用 


如 果 认为 GoldenGate 的 功能 只 是 简单 地 实现 一 些 跨 库 的 表 级 数据 同步 ， 那 就 真 错 了 。 我 们 说 这 些 只 是 GoldenGate 最 基本 的 功能 ， 基 于 基本 链 路 的 实现 原理 ， 可 以 衍生 出 高 级 应 用 。 比 如 ， 要 通过 
GoldenGate 实 现 数据 库 级 、 用 户 级 的 容 灾 或 者 数据 分 发 ， 通 过 一 个 表 一 个 表 的 这 样 去 对 应 ， 那 将 面临 非常 大 的 工作 量 。 那 应 该 如 何 去 实 现 呢 ? 接 下 来 我 们 将 展开 阐述 GoldenGate 的 高 级 应 用 。 


7.3.1 DDL 功能 支持 


在 基本 链 路 中 ，GoldenGate 是 不 支持 DDL 操 作 的 ， 对 于 表 与 表 的 数据 同步 完全 是 DML 操 作 层 面 的 ， 当 源 表 出 现 DDL 维 护 操作 ， 那 么 在 目标 表 上 也 必须 手工 进行 同样 的 维护 操作 。 这 对 于 用 户 级 和 数据 
库 级 的 复制 是 不 可 接受 的 ， 因 此 我 们 需要 让 GoldenGate 去 支持 DDL 操 作 。 当 然 ， 对 于 功能 强大 的 GoldenGate 工 具 来 说 ， 这 不 是 一 件 难事 。 


然而 ,我 们 也 必须 了 解 清楚 GoldenGate 对 Oracle 数 据 库 的 DDL 操 作 的 支持 情况 ， 因 为 它 不 是 支持 所 有 的 DDL。 详 情 如 表 7-3 所 示 。 


表 7-3 ”DDL 操作 支持 情况 


类 别 
DDL 支持 的 对 象 


clusters, 


tables, tablespaces, roles, 


说 


明 


functions, indexes, packages, procedure, 


SeEduences, 


synonyms, 


triggers, types, views, materialized views, users 


量 对 象 大 小 不 超过 2MB 


DDL 不 支持 的 用 户 


oracle 的 系统 用 户 的 DDL 操作 是 不 被 支持 的 ， 包 括 : 


ANONYMOUS, AURORA, $JIS, $UTILITY, $AURORA, $ORB, 
$UNAUTHENTICATED, CTXSYS, DBSNMP, DMSYS, DSSYS, 

EXFSYS, MDSYS, ODM, ODM MTR, OLAPSYS, ORDPLUGINS, 
ORDSYS, OSESHTTPS$ADMIN, OUTLN, PERFSTAT, PUBLIC, 


REPADMIN, SYS, 


SYSMAN, SYSTEM, 


WKSYS，WMSYS，XDB 等 


DDL 不 支持 的 操作 


DDL 操 


CREATE TABLE tl1 


如 下 DDL 操作 是 不 被 支持 的 : 
ALTER TABLE 


TRACESVR, WKPROXY, 


MOVE TABLESPACE 


ALTER DATABASE 
ALTER SYSTEM 

内 套 表 上 的 DDL 操作 
在 备 库 上 DDL 操作 


(a number, 


my_password); 


ALTER TABLE tl1 


ADD COLUMN Cc 


my_password; 


GoldenGate 也 是 很 周到 地 为 


户 考虑 到 了 操作 的 简易 性 ， 


步骤 1 指定 一 个 


户 (ggalex) 


作 中 包含 密码 加 密 信 息 的 也 是 不 被 支持 的 ， 如 下 示例 : 


b varchar2 (32) 


varchar2(64) 


使 GoldenGate 支 持 DDL 操 作 ， 只 需要 按部就班 地 执行 GoldenGate 的 内 置 封装 脚本 即 可 。 具 体 步骤 如 下 : 


于 控制 DDL 同 步 操作 ， 并 将 该 


户 信息 按 如 下 步骤 配置 到 GoldenGate 的 全 


局 环境 变量 文件 “$GGS_HOME/GLOBALS” 中 ， 示 例如 下 : 


$ cat >> $GGS HOME/GLOBALS <<EOF 
ggschema ggalex 
EOF 


步骤 2 ”在 Oracle 数 据 库 中 给 ggalex 用 户 授权 。 


SQL> grant execute on utl file to ggalex; 


步骤 3 ”如 下 顺序 执行 $GGS_HOME 目 录 下 的 DDL 功 能 脚本 。 


SQL> Q@marker setup.sql 

SQL> @ddl setup.sql 

SQL> @role setup.sql 

SQL> grant ggs ggsuser role to ggalex; 
SQL> @ddl enable.sql 

SQL> @ddl pin.sql ggalex 


上 述 脚本 的 功能 说 明 如 表 7-4 所 示 。 


脚 本 
marker setup.sql 
ddl setup.sql 
role setup.sql 
ddl enable.sql 
dal pin.sgl 


步骤 4 ”修改 源 端 捕获 进程 的 配置 文件 ， 将 DDL 支 持 选项 加 入 其 


表 7-4 DDL 脚 本 功能 说 明 


创建 Gold 


安装 Gold 


功能 说 明 
enGate 支持 DDL 操作 用 表 


enGate 支持 DDL 的 捕获 和 应 用 对 象 


创建 用 以 支持 DDL 操作 的 必要 角色 


开启 Golq 
用 于 提高 


中 


并 各 


时 启 捕获 进程 。 示 例如 下 : 


DDL 操 


enGate 用 以 支持 DDL 操 
作 支持 的 性 能 


$ cat >> $GGS HOME/dirprm/e source.prm <<EOF 
ddl include all 本 

EOF 

GGSCI (mysource) 1> stop e_source 

GGSCI (mysource) 2> start e source 


ENCRYPT IDENTIFIED 


ENCRYPT IDENTIFIED BY 


作 的 触发 需 


步骤 5 修改 目标 端 应 用 进程 的 配置 文件 ， 将 DDL 支 持 选项 也 加 入 其 中 ， 并 重启 应 用 进程 。 示 例如 下 : 


$ cat >> $GGS HOME/dirprm/r_source target.prm <<EOF 
ddl include all 

ddlerror default ignore retryop maxretries 3 retrydelay 5 
EOF 

GGSCI (mytarget) 1> stop r_source 

GGSCI (mytarget) 2> start 工 source 


至 此 ，GoldenGate 的 DDL 操 作 支 持 配 置 即 告 完 成 ， 可 以 在 源 数 据 库 创 建 一 个 空 表 alex.t1 测 试 一 下 ， 在 目标 数据 库 即 可 查询 到 该 表 ，DDL 同 步 支持 配置 成 功 。 


@ 源 数据 库 创建 空 表 : 


SQL> create table tl (id number primary key, name Varchar2 (10) ) 7 


@ 目 标 数 据 库 查询 验证 : 


SQL> select owner, table name from dba tables where table name="'T1'; 
OWNER TABLE NAME 


值得 注意 的 是 ，GoldenGate 对 数据 库 DDL 操 作 的 同步 支持 是 基于 一 个 数据 库 级 的 触发 器 来 引导 的 ， 是 面 对 整 库 的 ， 这 无 疑 也 增加 了 数据 库 本 身 的 负担 。 因 此 在 不 需要 DDL 同 步 支持 的 时 候 ， 尽 可 能 不 
要 安装 DDL 支 持 功能 ， 或 者 可 以 关闭 此 功能 。 


7.3.2 ”用 户 级 复制 


前 面 说 到 GoldenGate 的 容 灾 相 对 于 Data Guard 更 为 灵活 ， 其 灵活 之 处 就 在 于 它 不 仅 支持 表 级 的 同步 ， 也 支持 用 户 级 的 同步 ， 或 者 说 基于 SCHEMA 的 容 灾 。GoldenGate 能 灵巧 地 将 不 同 作用 的 
SCHEMA 同 步 到 不 同 的 目标 数据 库 ， 实 现 一 种 分 布 式 的 容 灾 ， 这 是 Data Guard 所 不 易于 实现 的 。 当 然 这 种 方式 的 容 灾 ， 我 更 愿意 称 之 为 “数据 分 发 ”。 


在 关系 型 数据 库 设 计 过 程 中 ， 我 们 不 可 避免 地 会 将 一 些 表 按 照 特定 的 关系 关联 起 来 ， 即 使 不 创建 相关 外 键 约束 ， 也 会 在 前 端 应 用 中 保证 数据 的 关联 性 。 这 就 形成 了 数据 的 一 种 耦合 关系 ， 不 论 是 强 耦 合 
还 是 弱 耦 合 ， 这 层 关系 都 是 不 容 忽视 的 。GoldenGate 在 进行 表 级 同步 的 时 候 ， 特 别 是 核心 表 ， 那 关联 关系 可 能 会 导致 我 们 不 得 不 同时 同步 多 张 表 。 与 其 去 重新 梳理 其 中 的 关系 ， 不 如 大 而 化 之 ， 对 整个 
SCHEMA 进 行 同步 。 如 果 反 向 推 ， 则 我 们 也 可 以 在 数据 库 建 模 阶段 特意 预 留 那么 几 个 SCHEMA 专 门 用 于 实现 数据 库 群 的 同步 。 


基于 一 个 或 多 个 用 户 的 SCHEMA 级 复制 ， 其 链 路 搭建 原理 和 步骤 与 基本 链 路 并 没有 什么 太 大 的 差异 。 然 而 ， 需 要 注意 的 是 ， 对 于 耦合 性 比较 强 的 数据 同步 最 好 在 同一 个 链 路 中 实现 。 因 为 这 是 一 种 “大 
而 化 之 ”的 做 法 ， 在 SCHEMA 级 复制 链 路 中 ， 尽 可 能 不 要 设置 表 级 的 列 转换 或 过 滤 功 能 ， 应 保持 源 数据 库 和 目标 数据 库 数据 结构 的 一 致 性 。 


下 面 通过 一 个 配置 实例 来 简单 介绍 一 下 SCHEMA 级 复制 链 路 的 搭建 吧 。 


首先 ， 需 要 按照 7.3.1 节 内 容 的 介绍 ， 安 装 DDL 支 持 功能 。 


其 次 ， 在 源 数 据 库 开启 相关 SCHEMA 下 所 有 待 同步 表 的 附件 日 志 ， 示 例如 下 : 


GGSCI (mysource) 1> add trandata alex.* 


最 后 ， 就 可 以 完全 仿照 基本 链 路 搭建 的 步骤 来 进行 了 。 所 不 一 样 的 是 ， 在 各 个 进程 的 参数 配置 上 需要 有 所 区 分 。 


在 源 端的 捕获 进程 配置 中 ， 不 需要 再 明确 指定 表 名 ， 使 用 “table alex.*” 作 为 替代 ， 表 示 待 同步 的 表 包 含 alex 用 户 下 的 所 有 表 。 如 果 需 要 在 同一 链 路 中 复制 多 个 用 户 的 SCHEMA， 则 逐一 添加 即 可 。 配 
置 文 件 示 例如 下 : 


$ cat > e source.prm <<EOF 
extract e_source 

obey ./diroby/env.oby 
exttrail ./dirdat/e0 

ddl include all 

table alex.*; 

EOF 


源 端的 数据 泵 进程 配置 可 以 参照 捕获 进程 的 配置 ， 不 要 指定 具体 的 表 名 ， 示 例如 下 : 


$ cat > d source target.prm <<EOF 
extract d target 

obey ./diroby/env.oby 

rmthost mytarget, mgrport 8809 
rmttrail ./dirdat/dl 

table alex.*; 

EOF 


尽管 我 们 进行 的 是 SCHEMA 级 别 的 复制 ， 但 其 实现 原理 还 是 像 基 本 链 路 的 表 级 别 复制 一 样 ，SCHEMA 级 别 的 复制 只 是 将 SCHEMA 内 的 一 组 表 进行 了 “打包 ”处 理 。 因 此 ， 需 要 目标 数据 库 能 够 识别 跟 
踪 日 志文 件 的 格式 ， 还 是 需要 在 源 端 生成 一 个 所 有 表 的 定义 文件 ， 并 传输 到 目标 端 。 在 生成 定义 文件 的 配置 文件 中 ， 也 需要 向 捕获 进程 配置 文件 一 样 ， 指 定 alex 用 户 的 所 有 表 ， 如 下 所 示 : 


$ cat > source.prm <<EOF 

defsfile ./dirdef/source.def, purge 

userid ggalex, password AADAAAAAAAAAAAGAU....MEJBOESF, encryptkey mykey 
table alex.*; 

EOF 


而 在 目标 端的 应 用 进程 配置 中 ， 因 为 我 们 限定 了 要 求 所 有 表 同 构 的 复制 ， 所 以 在 map 参 数 中 不 需要 再 明细 罗列 所 有 表 和 字段 的 对 应 关系 ， 简 单 地 写成 “map alex.*，target alex.*” 即 可 。 配 置 文件 示 
例如 下 : 


$ cat > r source target.prm <<EOF 

replicat r source 

obey ./diroby/env.oby 

sourcedefs ./dirdef/source.def 

discardfile ./dirrpt/r alex.dsc, append 

ddl include all 

ddlerror default ignore retryop maxretries 3 retrydelay 5 
map alex.*, target alex.*; 

EOF 


配置 文件 修改 完成 之 后 ， 重 新 生成 def 定 义 文件 ， 并 传输 到 目标 端 主机 。 最 后 ， 重 启 所 有 发 生 了 配置 变更 的 进程 即 可 。 


值得 特别 注意 的 是 ， 与 Data Guard 的 同步 方式 不 一 样 ，GoldenGate 无 法 实现 系统 表 、 数 据 字典 及 其 自身 功能 表 的 数据 复制 ， 进 而 就 无 法 实现 数据 库 级 别 的 复制 ， 这 似乎 与 一 些 宣传 报道 产生 了 分 歧 。 
其 实 不 然 ， 使 用 GoldenGate 实 现 全 库 的 复制 也 是 基于 SCHEMA 级 别 的 复制 来 进行 的 。 比 如 ， 在 一 个 Oracle 数 据 库 中 有 10 个 系统 用 户 的 SCHEMA 和 30 个 自 创 建 的 用 户 SCHEMA， 那 么 就 在 GoldenGate 的 复 
制 链 路 中 仅 配 置 30 个 自 创 建 的 用 户 SCHEMA 的 复制 ， 即 实现 了 应 用 程序 的 全 库 复 制 (因为 10 个 系统 用 户 SCHEMA 的 数据 对 于 前 端 应 用 程序 是 没有 影响 的 ) 。 可 以 看 到 ，GoldenGate 的 全 库 复 制 实质 上 是 一 
种 间接 的 实现 ， 一 定 程度 上 也 印证 了 GoldenGate 不 如 Data Guard 更 适合 做 容 灾 的 说 法 。 


7.4 “ 噶 构 数据 库 群 


众 所 周 之 ，GoldenGate 之 所 以 能 够 成 为 GoldenGate， 很 大 程度 上 是 因为 它 是 一 个 可 以 跨 平台 跨 数 据 库 的 数据 集成 工具 ， 依 靠 它 能 够 构建 出 一 个 异 构 的 数据 库 集成 环境 ， 可 以 将 不 同 平台 、 不 同类 别 的 
数据 库 整合 成 一 个 分 布 式 数据 库 群 。 


说 起 异 构 集成 ， 大 家 的 第 一 反映 要 么 是 平台 异 构 ， 要 么 是 数据 库 异 构 ， 然 而 ， 在 实际 使 用 中 ， 这 两 种 情况 比 异 构 字符 集 的 情况 要 少 。 我 们 可 以 将 异 构 的 情况 大 致 分 为 以 下 三 大 类 : 


异 构 字 符 集 间 复 制 ; 


“ 异 构 哥 作 系统 平 台 间 复制 ; 


“ 异 构 数据 库 产 品 间 复 朵 


1 。 


异 构 操作 系统 平台 的 问题 ， 其 实 GoldenGate 已 经 帮 有 我 们 解决 了 ， 它 提供 了 不 同 平台 的 不 同安 装 版 本 ， 只 需要 进行 安装 介质 的 区 分 即 可 ， 在 GoldenGate 环 境内 的 配置 则 是 大 同 小 异 的 。 


对 于 异 构 字符 集 和 异 构 数 据 库 产品 的 情况 ， 我 们 将 在 接 下 来 的 篇 幅 中 展开 介绍 一 下 具有 典型 性 的 案例 。 


74.1 ” 异 构 字符 集 数 据 库 间 复 制 


数据 库 字符 集 不 同 难道 也 算是 异 构 情况 吗 ” 当 然 是 ， 面 对 同一 种 数据 库 产 品 ， 使 用 不 同 的 字符 集 ， 虽 然 可 以 在 导入 导出 过 程 中 进行 字符 集 转换 ， 但 是 在 数据 集成 时 ， 如 果 没 有 做 好 转换 ， 产 生 乱 码 ， 导 
致 数据 不 可 用 ， 其 危害 是 不 可 小 视 的 。 


虽然 很 多 公司 都 在 给 数据 库 应 用 制定 这 样 那样 的 规范 ， 但 是 规范 不 是 从 来 就 有 的 ， 历 史 遗 留 和 外 购 系统 的 问题 导致 了 数据 库 应 用 中 出 现 了 大 相 径 庭 的 数据 库 字 符 集 。 在 Oracle 数 据 库 中 ， 其 字符 集 在 数 
据 库 创建 时 确定 ， 且 一 经 确定 就 不 能 修改 ， 除 非 进行 数据 库 重 构 。 相 信 谁 也 不 会 因为 字符 集 的 问题 去 重 构 数据 库 的 ， 那 么 如 何在 数据 复制 过 程 中 做 好 转换 就 成 了 异 构 集成 的 关键 所 在 。 


在 不 同 字符 集 间 转 换 ， 可 能 造成 以 下 两 方面 的 影响 : 


“ 复制 数据 在 目标 端 字段 长 度 不 足 ， 应 用 进程 中 断 ; 
“ 复制 数据 (主要 指 中 文 ) 在 目标 端 出 现 乱 码 。 


很 显然 ， 这 两 种 情况 都 是 不 能 被 接受 的 。 然 而 ， 出 现 乱 码 是 可 以 通过 转换 来 进行 补救 的 ， 而 数据 在 目标 端 长 度 是 无 法 补救 的 。 以 中 文字 符 的 存储 为 例 来 进行 对 比 ， 在 两 种 常见 的 字符 集 类 型 AL32UTF8 
和 ZHS16GBK 间 ， 其 关系 如 表 7-5 所 示 。 


表 7-5 “ 异 构 字符 集 的 中 文 转换 说 明 


源 字符 集 源 字 段 类 型 “| 目标 字符 集 | 目标 字段 类 型 说 明 
符 ， 
可 插入 3 个 中 文字 符 ， 占 9 个 字 节 ， 目 标 端 字段 


ZHS16GBK |VARCHAR2 (6) |AL32UTF8 |VARCHAR2 (9) 
i 长 度 足 够 ， 正常 复制 
ZHS16GBK |VARCHAR2 (6) |AL32UTF8 |VARCHAR2 (6) | 口 目标 库 字 符 集 为 源 库 字符 集 的 超 集 ， 无 须 字 符 集 
转换 
口 源 端 可 插入 3 个 中 文字 符 ， 占 6 个 字 节 ， 目 标 端 可 
插入 2 个 中 文字 符 ， 占 6 个 字 节 ， 目 标 端 字段 长 度 
不 够 ， GoldenGate 报错 ， 应 用 进程 异常 中 断 
AL32UTF8 |VARCHAR2 (9) |ZHS16GBK |VARCHAR2 (6) | 口 源 库 字 符 集 为 目标 库 字符 集 的 超 集 ， 需 要 字符 集 
转换 
口 源 端 可 插入 3 个 中 文字 符 ， 占 9 个 字 节 ， 目 标 端 
可 插入 3 个 中 文字 符 ， 占 6 个 字 节 ， 目 标 端 字 段 
长 度 足 够 ， 正 常 复制 


由 此 可 见 ， 如 果 源 端的 数据 实际 长 度 不 超过 目标 端的 列 最 大 字 节 长 度 ， 则 正确 配置 的 前 提 下 可 以 正常 同步 ， 如果 源 端的 数据 实际 长 度 超过 了 目标 端 列 的 最 大 字 节 长 度 ， 则 会 出 现 应 用 进程 中 断 ， 同 时 在 
日 志 中 会 出 现 告警 信息 。 


口 目标 库 字 符 集 为 源 库 字 符 集 的 超 集 ， 无 须 字符 集 
全 鬼 
口 源 端 可 插入 3 个 中 文字 占 6 个 字 节 ， 目 标 端 


而 在 异 构 字符 集 间 保 证 数据 转换 的 正确 配置 ， 主 要 通过 以 下 两 种 方式 来 实现 。 


“ 在 数据 转换 的 过 程 中 ， 通 过 OCI 方 式 来 实现 。 如 下 例 所 示 ， 需 要 修改 前 面 创建 的 环境 变量 设置 文件 env.oby， 强 制 使 目标 端的 字符 集 环境 变量 与 源 端 保持 一 致 。 添 
加 “SETENV (NLS_LANG="AMERICAN_AMERICA.AL32UTF8") ”， 该 参数 为 环境 变量 ， 必 须 在 登录 数据 库 之 前 进行 设置 ，AL32UTF8 为 源 数据 库 字符 集 。 


$ cat > $GGS HOME/diroby/env.oby <<EOF 

SETENV (NLS_ LANG="AMERICAN AMERICA.AL32UTF8") 

SETENV (ORACLE SID = "target") 

userid ggalex, password AADAAAAAAAAAAAG....SF, encryptkey mykey 
EOF 


“ 在 GoldenGate 的 应 用 进程 中 ， 配 置 CHARSETCONVERSION 参 数 来 进行 转换 。 只 需要 在 目标 端 应 用 进程 配置 文件 中 追加 该 参数 即 可 。 注 意 需要 同时 有 SOURCEDEEFS 参 数 的 配置 〈 因 为 前 面 例子 中 已 有 
配置 方式 ， 此 处 不 宛 述 ) ， 如 下 所 示 。 


$ cat >> $GGS HOME/dirprm/r_source target.Prm <<EOF 
SOURCEDEFS ./dirdef/source.def 

CHARSETCONVERSION 

EOF 


以 上 两 种 转换 方式 不 要 同时 使 用 ， 否 则 会 造成 不 必要 的 系统 资源 消耗 。 通 常情 况 下 ， 还 是 比较 推荐 通过 OCI 方 式 来 进行 转换 ，OCI 方 式 不 能 实现 的 情况 下 ， 才 考虑 使 用 CHARSETCONVERSION 参 数 的 
方式 ， 因 为 CHARSETCONVERSION 参 数 方式 是 在 11.2 版 本 首次 引入 ， 在 早期 版 本 中 无 法 使 用 ， 其 稳定 性 也 不 如 OCI 方 式 。 


下 面 我 们 通过 实例 来 验证 一 下 表 7-5 中 的 三 种 情况 的 执行 结果 。 


情况 1: 源 库 为 ZHS16GBK 字 符 集 ， 目 标 库 为 AL32UTF8 字 符 集 ， 测 试用 表 t_ggs_711 在 两 个 库 上 的 定义 如 下 所 示 ， 字 段 C1 在 目标 端 长 度 足够 。 


一- 源 库 ZHS16GBK 

SQL> desc t_ggs_711 

Name Type Nullable Default Comments 
ID NUMBER 

cl VARCHAR2(6) 了 

一 -目标 库 AL32UTF8 

SQL> desc t ggs 711 

Name Type Nullable Default Comments 
ID NUMBER 


Cl VARCHAR2(9) Y 


当 源 库 发 生 一 行 记 录 插 入 后 ， 可 以 看 到 在 源 库 和 目标 库 中 的 中 文 都 正常 显示 了 ， 但 是 其 二 进 制 编码 是 不 一 样 的 ， 这 是 由 字符 集 来 决定 的 ， 说 明 复制 过 程 自动 完成 了 字符 集 的 转换 ， 因 为 AL32UTF8 字 符 
集 是 ZHS16GBK 字 符 集 的 超 集 。 查 询 结果 如 下 所 示 : 


一 - 源 库 ZHS16GBK 

SQL> select cl1l, dump(c1) from t ggs 711; 

el DUMP (C1) 

我 是 谁 ”Typ=1 Len=6: 206,210,202,199,203,173 

一 -目标 库 AL32UTF8 

SQL> select id, cl, dump(c1) from t ggs 711; 

ey DUMP (C1) 

我 是 谁 Typ=1 Len=9: 230,136,145,230,152,175,232,176,129 


情况 2: 源 库 为 ZHS16GBK 字 符 集 ， 目 标 库 为 AL32UTF8 字 符 集 ， 测 试用 表 t_ggs_711 在 源 库 上 的 定义 不 变 ， 而 在 目标 库 上 其 字段 C1 由 VARCHAR2 (9) 变 为 VARCHAR2 (6) ， 如 果 仍 然 插 入 3 个 中 文字 
符 ， 其 长 度 就 不 够 了 。 验 证 如 下 ， 源 库 数 据 正 常 完成 插入 ， 而 目标 库 没有 数据 同步 。 


=-- 源 库 ZHS16GBK 

SQL> select c1，dump (cl1) from t ggs 711; 

el DUMP (C1) 加 

我 是 谁 ”Typ=1 Len=6: 206,210,202,199,203,173 
一 -目标 库 AL32UTF8 

SQL> select id, cl, dump(c1) from t ggs 711; 
et DUMP (C1) 


此 时 ， 在 目标 端 看 到 其 应 用 进程 RSOURCE 出 现 异常 中 断 了 。 如 下 所 示 : 


GGSCI (cnsh230234) 1> info r source 
Program Status Group Lag at Chkpt Time Since Chkpt 
REPLICAT ABENDED R_SOURCE 00:20:02 00:02:19 


检查 错误 日 志 ， 可 以 看 到 如 下 信息 。 发 现 提示 在 目标 库 上 字段 C1 长 度 不 足以 容纳 新 值 。 


WARNING OGG-01004 .....: Aborted grouped transaction on 'ALEX.T GGS 711', Database error 12899 (OCI Error ORA-12899: value too large for column "ALEX"."T GGS 711"."C1" (actual: ¢ 
ERROR OGG-01296 ....: Error mapping from ALEX.T GGS 711 to ALEX.T GGS 711. 
ERROR OGG-01668 .…: PROCESS ABENDING. 


对 于 字段 长 度 不 足 的 情况 ， 基 本 上 是 没有 很 好 的 办 法 来 解决 的 ， 即 使 强制 使 用 OCI 方 式 进行 转换 ， 也 是 会 出 现 乱 码 ， 因 此 需要 在 设计 时 就 给 目标 端 预 留 足够 的 字段 长 度 ， 特 别 是 要 进行 字符 集 转换 的 情 
况 。 


情况 3: 源 库 为 AL32UTF8 字 符 集 ， 目 标 库 为 ZHS16GBK 字 符 集 ， 测 试用 表 t_ggs_711 在 两 个 库 上 的 定义 如 下 所 示 ， 字 段 C1 在 目标 端 长 度 足够 (因为 字符 集 有 差异 ) 。 


一 - 源 库 RL32UTF8 

SQL> desc t_ggs_711 

Name Type Nullable Default Comments 
ID NUMBER 

cl VARCHAR2 (9) Y 

一 目标 库 ZHS16GBK 

SQL> desc t ggs 711 

Name Type Nullable Default Comments 
ID NUMBER 


Cl VARCHAR2(6) Y 


当 源 库 发 生 一 行 记录 插入 后 ， 在 目标 库 中 的 中 文 显示 出 现 乱 码 ， 因 为 AL32UTF8 字 符 集 是 ZHS16GBK 字 符 集 的 超 集 ， 目 标 端 无 法 自动 完成 字符 集 转换 ， 从 其 二 进 制 编码 可 以 看 到 ， 两 个 库 是 一 致 的 ， 而 
此 二 进 制 编码 方式 为 AL32UTF8 字 符 集 的 ， 在 ZHS16GBK 字 符 集中 不 经 转换 是 无 法 识别 的 ， 乱 码 产 生 。 查 询 结 果 如 下 所 示 : 


一 - 源 库 AL32UTF8 
SQL> select cl1l, dump(c1) from t ggs 711; 
cl DUMP (C1) 


-- 目 标 库 ZHS16GBK 
SQL> select id, cl, dump(c1) from t ggs 711; 
cl DUMP (C1) 


a^ "va~ e”yYp=1 Len=9: 230,136,145,230,152,175,232,176,129 


此 时 ， 我 们 就 需要 通过 上 述 两 种 方式 来 进行 字符 集 转换 了 。 
构 字符 集 的 复制 往往 不 会 得 到 足够 的 重视 ， 导 致 数据 出 现 乱 码 。 在 数据 库 的 设计 中 ， 往 往 是 细节 决定 成 败 ， 等 到 问题 产生 再 去 补救 ， 代 价 必定 是 很 大 的 。 在 复制 链 路 的 设计 之 初 ， 就 应 该 要 考虑 到 
表 、 字 段 、 字 符 集 异 构 的 兼容 性 。 


7.4.2” 异 构 数 据 库 间 复制 


对 于 GoldenGate 来 说 ， 在 异 构 数 据 库 间 复制 数据 是 没有 什么 特异 性 的 ， 与 在 纯 Oracle 数 据 库 环境 下 复制 数据 的 原理 和 配置 方式 都 是 差不多 的 。 主 要 需要 注意 以 下 三 方面 的 问题 : 


(1) 安装 与 配置 


安装 介质 方面 ，GoldenGate 已 经 帮 有 我们 作 了 区 分 ， 只 需要 下 载 对 应 平台 和 数据 库 的 安装 介质 即 可 ; 在 配置 方面 ， 其 区 别 在 于 异 构 数据 库 的 不 同 连 接 方式 ， 需 要 加 以 区 分 ， 而 GoldenGate 本 身 的 配置 方 
式 则 是 没有 什么 区 别 的 。 


(2) 支持 的 数据 类 型 


在 不 同 的 数据 库 中 ，GoldenGate 也 有 其 支持 的 特有 字符 集 和 字段 类 型 。Oracle 数 据 库 的 支持 情况 在 前 面 已 经 介绍 过 了 。 如 果 在 异 构 数据 库 环境 中 ， 存 在 Oracle 与 MySQL 之 间 的 复制 ， 那 还 需要 考虑 
MySQL 的 支持 情况 。 具 体 如 下 : 


“ MySQL 数 据 库 中 ，GoldenGate 只 支持 Innodb 的 存储 引擎 ， 因 为 GoldenGate 需 要 完整 的 日 志 信息 。 
“MySQL 数据 库 字 符 集 支持 UTF8， 但 不 支持 UTF32。 
"Oracle 与 MySQL 的 字段 类 型 需要 完全 匹配 ， 其 各 自 独 有 的 字段 类 型 不 可 以 使 用 ， 数 据 库 字段 类 型 的 对 有 照 关系 如 表 7-6 所 示 。 


表 7-6 Oracle 与 MYSQL 字 段 类 型 对 照 表 


类 型 Oracle 数据 库 MySQL 数据 库 
数值 型 NUMBER INT 
BINRRY FLOAT TINYINT 
BINARY DOUBLE SMALL INT 
MEDIUM INT 
BIG INT 
UINT64 
DECIMAL 
FLOAT 
DOUBLE 
ENUM 
字符 型 CHAR CHAR 
VARCHAR2 VARCHAR 
LONG 
NCHAR 
NVARCHAR2 
二 进 制 型 RAW BINARY 
LONG RAW VARBINARY 
BIT (M) 
日 期 型 DATE DATE 
TIMESTAMP TIME 
YEAR 
DATETIME 
TIMESTAMP 
大 对 象 型 CLOB TBT 
NCLOB TINYTEXT 
BLOB MEDIUMTEXT 
SECUREFILE and BASICFILE LONGTEXT 
BLOB 
TINYBLOB 
MEDIUMBLOB 
LONGBLOB 
(3) DDL 复 制 


在 异 构 的 数据 库 环 境 中 ， 不 论 是 否 能 够 支持 DDL 操 作 的 复制 ， 都 不 要 使 用 。 


使 用 GoldenGate 进 行 数据 库 间 的 数据 复制 ， 其 本 质 上 都 是 通过 客 
应 用 跟踪 日 志 。 其 中 ， 转 换 成 统一 格式 的 GoldenGate 跟 踪 日 志文 件 ， 是 其 实现 异 构 数 


GoldenGate 能 够 支持 ， 但 是 在 异 构 环境 中 不 建议 使 用 ， 避 免 日 志 转 换 划 


7.5 ”本章 小 结 


纵 观 本 章 ， 主 要 阐述 了 Oracle 的 数据 集成 工具 GoldenGate 在 构建 高 并 发 数 所 
展 更 为 多 样 化 。 在 下 一 章 中 ， 我 们 将 给 读者 介绍 Data Guard 的 特殊 使 用 


第 8 章 ”Data Guard 的 妙用 


本 章 要 点 : 


“T-1” 交 易 数据 库 ， 介 绍 Data Guard 功 能 非 主流 用 法 。 


端 连接 (一 条 链 路 ) 到 源 数据 库 ， 将 其 日 志 信息 挖掘 出 来 并 转换 成 统一 格式 的 GoldenGate 跟 踪 日 志 ， 并 在 目标 端 通过 客户 端 连接 并 
居 库 间 数 据 复制 的 关键 所 在 。 然 而 ， 对 于 一 些 比较 大 的 字段 类 型 (比如 : Oracle 的 LOB、LONG 等 ) ， 虽 然 
来 的 较 大 开销 ， 进 而 影响 到 整 条 复制 链 路 。 


居 库 体系 中 的 积极 作用 ， 拓 展 设计 思路 的 同时 ， 深 入 介绍 了 GoldenGate 的 数据 集成 原理 ， 以 及 链 路 搭建 与 监控 ,使 得 纵横 扩 
方式 ， 使 得 原本 简单 熟悉 的 技术 手段 更 具 使 用 价值 。 


“ ADG 实 现 读 写 分 离 ， 介 绍 使 用 Active Data Guard 实 现 自动 的 数据 库 读 写 分 离 


Data Guard 是 Oracle 的 一 种 高 可 
可 以 实现 数据 库 快速 切换 和 灾难 性 恢复 ， 而 且 其 
(Oracle 11g 新 引进 的 Active Data Guard 需 要 额外 费 


本 章 将 “ 剑 走 偏锋 ”， 以 非常 规 的 方式 来 运 


性 数据 库 方案 ， 在 9i 之 前 被 称 为 备份 数据 库 (Standby Database) ， 
同步 方式 对 主 库 的 影响 非常 小 ， 主 备 库 之 问 的 数据 差异 仅 限 于 在 线 日 志 部 分 。 更 为 难得 的 是 ， 


8.1 -1” 交 易 数据 库 


T-1” 的 概念 ， 大 家 可 能 会 


是 登记 日 的 次 日 。 引 用 股票 交易 市 场 的 这 个 概念 ， 


8.1.1 ”实现 原理 与 应 用 场景 


这 样 一 个 “T-1” 交 易 数据 库 有 什么 作 


Js 


因此 ， 被 众多 企业 


比较 陌生 ,但 是 “T+ 1” 想 必 就 比较 熟悉 了 吧 。 


作 数 据 容 灾 解决 方案 。 


“+1” 是 一 种 股票 交易 制度 ， 即 当日 买 进 的 股票 ， 


Data Guard 功 能 ， 使 其 不 再 仅仅 是 一 个 容 灾 方 案 的 功能 组 件 ， 更 能 用 于 解决 高 并 发 问题 。 


从 9i 开 始 ， 正 式 更 名 为 Data Guard。 它 通过 在 主 库 与 备 库 之 间 进 行 日 志 同 步 来 保证 数据 同步 ， 
户 不 必 为 Data Guard 购 买 任何 组 件 ， 不 会 产生 额外 的 费 F 


呢 ? 对 高 并 发 问题 的 解决 又 有 什么 积极 意义 呢 ? 接 下 来 我 们 将 具体 展开 阐述 ， 来 看 一 下 “T-1” 


T-1” 交 易 数 据 库 的 实现 原理 和 应 用 场景 ， 如 图 8-1 所 示 。 从 应 用 场景 来 看 ， 


我 们 可 以 将 在 线 业务 应 用 和 离线 分 析 应 用 的 工作 区 分 开 。 


:在线 应 用 : 这 部 分 应 用 是 数据 库 最 关键 的 应 用 ， 直 接 对 应 的 是 实时 的 业务 操作 ， 必 须 保 证 其 可 用 性 的 ， 也 是 最 有 可 能 产生 高 并 发 问题 的 应 用 。 


“ 离线 应 用 : 包括 数据 采集 、 报 表 分 


如 果 没有 一 个 独立 于 实时 交易 数据 库 的 数据 库 ， 离 线 应 


折 、DBA 自身 的 性 能 诊断 与 优化 等 工作 。 


要 到 下 一 个 交易 日 才能 卖 出 ，“T” 是 指 交 易 登记 日 ，“T+ 1” 则 指 的 


交易 数据 库 如 何 使 用 。 


T-1” 就 是 交易 登记 日 的 前 一 日 ， 因 此 “T-1” 交 易 数据 库 就 是 交易 数据 库 前 一 个 交易 日 的 映像 数据 库 。 


大 增加 。 如 果 并 发 问题 较为 严重 


性 能 优化 


数据 复制 


rc 


时 ， 想 要 予以 解决 也 会 有 投 鼠 尽 器 之 感 。 


数据 采集 


T-l 


的 这 些 工 作 都 将 要 在 实时 交易 数据 库 上 进行 了 ， 这 无 疑 加 大 了 其 负载 压力 ， 而 复杂 零乱 的 应 用 场景 也 势必 导致 实时 交易 数据 库 出 问题 的 概率 大 


报表 分 析 


在 线 应 用 


交易 数据 库 


记录 日 志 


一 


存储 复制 


Data Guard 


I 


COOKIEIOKCOESETEKD 
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相信 很 多 较为 专业 的 公司 对 在 线 应 


“ 离线 分 析 数 据 延 时 足够 短 ， 报 表 出 具足 够 快 ; 


“ 架构 实现 足够 简单 和 廉价 。 


和 离线 分 析 都 做 了 很 好 的 区 分 ， 但 是 实现 手段 上 是 否 做 到 足够 合理 呢 ? 所 谓 


当然 ， 我 们 可 以 使 用 ETL 工 
牛刀 了 。 


创建 数据 仓库 ， 然 后 一 步 一 


步 地 去 实现 数据 集 市 、 


数据 库 回 退 


图 8-1 “T-1” 交 易 数 据 库 原 理 
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合理 ， 无 非 是 以 下 两 点 : 


数据 立方 等 工作 。 从 长 远 来 看 ， 大 规模 地 应 | 


无 疑 是 不 错 的 选择 ， 


但 如 果 只 是 为 了 实现 一 些 简单 的 分 析 ， 似 乎 就 成 了 杀 鸡 


如 果 直 接 使 用 Data Guard 构 建物 理 备 库 呢 ? 即使 是 Oracle 119 新 引进 的 Active Data Guard， 也 只 能 是 只 读 功 能 的 实现 ， 对 于 一 些 传统 行业 的 报表 分 析 应 用 ， 不 能 支持 写 的 操作 ， 那 就 相当 于 分 析 业 务 


无 法 实现 。 


那么 ， 使 用 第 7 章 介 绍 的 GoldenGate 功 能 呢 ? 当然 ， 写 的 操作 是 
问题 ， 导 致 数据 不 一 致 。 使 用 GoldenGate 来 完成 这 项 工作 ， 就 需要 改造 一 下 目标 库 和 对 应 的 分 析 业 务 应 


回 到 图 示 8-1 中 ， 通 过 “T-1” 


“ 存储 复制 : 这 是 在 存储 层面 实现 的 一 种 复制 技术 ， 
实时 库 基 于 该 时 点 的 映像 库 。 该 方法 非常 简单 快捷 ， 而 且 影响 较 小 ， 然 而 ， 存 储 


交易 数据 库 则 可 以 较为 轻松 地 实现 上 述 功 能 


对 于 数据 库 来 说 是 透明 的 ， 实 时 库 和 “T 


实现 了 ， 数 据 同步 的 延 时 也 足够 短 了 ， 但 是 费 


1” 库 是 完全 独立 开 的 ， 在 完全 全 量 复制 后 


复制 技术 的 应 用 需要 较 高 的 费用 ， 不 适合 中 小 型 的 数据 库 应 用 。 


也 大 幅度 增加 了 。 如 果 在 GoldenGate 的 目标 表 直 接 进 行 数据 的 变更 ， 可 能 会 出 现 链 路 
， 这 个 动作 就 比较 大 了 ， 相 当 于 新 建 了 一 套数 据 库 。 


。 在 数据 复制 部 分 ， 需 要 保证 实时 交易 数据 库 的 数据 能 够 按照 特定 时 点 复制 到 “T-1” 库 ， 可 以 通过 以 下 两 种 手段 来 实现 。 


只 需要 在 特定 时 点 进行 增 量 复制 ，“T-1” 库 就 能 够 轻松 成 为 


“ Data Guard 复制: Oracle 从 10g 开 始 ， 引 进 了 Flashback ( 闪 回 ) 功能 ， 我 们 可 以 结合 使 用 Data Guard 和 Flashback 两 项 功能 ， 在 不 产生 额外 费用 的 前 提 下 实现 “T-1” 交 易 数据 库 的 架构 。 


如 图 8-1 所 示 ，Data Guard 物 理 备 库 结合 Flashback 功 能 来 实现 “T-1” 数 据 库 在 原理 上 并 不 复杂 。 初 始 状态 “T-1” 库 为 实时 库 的 一 个 物理 备 库 ， 假 设 从 每 天 的 0 点 开放 “T-1” 库 的 对 外 服务 ， 那 么 可 
以 按 如 下 步骤 进行 配置 : 


步骤 1 在 “T-1” 库 上 先 创 建 一 个 0 点 的 Flashback 闪 回 点 ， 再 以 独立 数据 库 的 方式 打开 “T-1” 库 ， 提 供 对 外 服务 。 


步骤 2 “T-1” 库 会 记录 自己 的 日 志 ， 并 且 暂 时 中 断 主 库 变 更 的 日 志 应 用 。 


步骤 3 在 24 点 (下 一 个 0 点 ) 到 来 的 时 候 ， 使 用 Flashback 功 能 将 “T-1” 库 回 退 到 0 点 ， 并 以 物理 备 库 的 方式 打开 “T-1” 数 据 库 ， 应 用 主 库 传输 过 来 的 日 志 ， 完 成 其 与 主 库 间 的 数据 同步 。 


回 


步骤 4 “完成 数据 同步 后 ， 再 开始 新 一 轮 的 创建 内 回 点 和 对 外 服务 。 


“T-1” 数 据 库 虽 然 不 能 直接 解决 高 并 发 的 问题 ， 但 是 能 够 将 大 部 分 非 实时 的 业务 从 生产 库 分 离 出 来 ， 大 大 降低 了 生产 库 出 现 高 并 发 问题 的 概率 。 而 实际 上 ， 能 实现 “T-1” 交 易 数据 库 的 方式 有 很 多 ， 
但 既 简 单 又 廉价 ， 同 时 能 保证 稳定 的 周期 性 延 时 的 ， 本 例 这 种 方式 将 是 不 二 之 选 。 接 下 来 的 篇 幅 将 主要 围绕 Data Guard 结 合 Flashback 这 种 方式 来 展开 介绍 。 


8.1.2 “T-1” 备 库 简 介 


对 于 大 多 数 Oracle 的 DBA 来 说， 想必 Data Guard 是 再 熟悉 不 过 的 了 ， 特 别 是 物理 备 库 的 实现 ， 可 以 称 得 上 是 Oracle 数 据 库容 灾 的 标准 配置 方案 。 


下 面 我 们 通过 一 个 图 示 来 简单 介绍 一 下 Data Guard 的 工作 原理 。 图 8-2 为 Oracle 10g 环 境 下 Data Guard 的 实现 原理 ， 其 中 展示 的 是 较为 常用 的 通过 主 库 LGWR (Log writer) 进程 (负责 数据 库 的 
REDO 日 志 写 入 工作 ) 进行 异步 日 志 传输 ， 且 非 实时 应 用 (实时 应 用 的 实现 方式 参见 图 中 虚线 箭头 部 分 ) 的 场景 。 


RFS 


REDO 日 志 


归档 日 志 
MRP 


8-2 Data Guard 原 理 图 


在 主 库 中 ，LGWR 进 程 写 入 主 库 REDO 日 志 的 同时 ， 将 主 库 日 志 信息 通过 网 络 服务 进程 LNSn 传 输 到 备 库 端 ， 因 为 是 异步 传输 方式 ， 所 以 LGWR 进 程 的 写 入 日 志 行 为 和 传输 日 志 行为 是 互 不 影响 的 。 在 备 
库 端 ， 数 据 库 通过 RFS (Remote file server) 进程 接收 来 自主 库 的 日 志 信 息 ， 并 且 将 其 写 入 到 备 库 的 REDO 日 志 中 (或 者 直接 写 入 备 库 的 归档 日 志 中 ) ， 再 通过 备 库 的 ARCn (Archiver) 进程 写 入 到 归档 日 
志 中 。 最 后 ， 由 备 库 的 MRP (Managed recovery) 进程 应 用 日 志 信息 到 备 库 (因为 本 例 使 用 的 是 物理 备 库 ， 故 使 用 MRP 进 程 应 用 日 志 ， 如 果 是 逻辑 备 库 ， 则 应 用 日 志 的 进程 为 LSP 进 程 ) 。 


如 此 看 来 ，Data Guard 的 实现 原理 并 不 复杂 ， 其 核心 部 分 就 是 主 备 库 间 的 日 志 传输 与 应 用 。 如 果 将 备 库 做 成 “T-1” 交 易 数据 库 ， 那 么 在 其 以 读 写 方式 打开 期 间 ， 日 志 是 暂停 被 应 用 的 。 


8.1.3 “T-1” 库 内 回 简介 


闪 回 (Flashback) 功能 是 Oracle 数 据 库 从 10g 开 始 正式 引入 的 新 特性 (在 9i 中 ， 已 经 可 以 支持 基于 UNDO 数 据 的 闪 回 查询 了 ) ， 也 是 “T-1” 交 易 数据 库 技术 能 够 得 以 实现 的 关键 所 在 。 


从 Oracle 10g 开 始 ， 闪 回 功能 不 仅 支持 Flashback 查 询 ， 还 支持 表 级 和 数据 库 级 的 Flashback 操 作 ， 有 具体 的 应 用 场景 和 技术 如 表 8-1 所 示 。 


表 8-1 闪 回 技术 与 应 用 场景 


及 EE 

数据 库 大 批量 的 误 操作 使 用 内 回 日 志 进 行内 回 
删除 表 使 用 回收 站 进行 闪 回 

表 误 DML 操作 使 用 UNDO 数据 闪 回 
行 历史 版 本 对 比 使 用 UNDO 数据 进行 历 


事务 数据 历史 时 点 状态 查询 使 用 UNDO 数据 进行 历 


史 查 询 
史 查 询 


在 实现 “T-1” 数 据 库 的 架构 中 ， 我 们 需要 的 是 数据 库 级 别 的 闪 回 功能 来 配合 Data Guard 的 操作 。 同 样 ， 我 们 通过 一 张 图 来 解读 一 下 数据 库 级 的 Flashback 功 能 ,其 原理 如 图 


Es 
数据 库 


归档 日 志 


基于 时 点 或 
SCN 的 闪 回 


基于 闪 回 点 获取 归档 
的 内 回 日 志 信 息 


发 起 闪 回 


Flashback 日 志 


图 8-3 数据库 级 闪 回 操作 原理 图 


8-3 所 示 。 


假设 数据 库 在 0 点 时 开启 了 Flashback 功 能 ， 并 在 1 点 创建 了 一 个 闪 回 点 ， 当 数据 库 运 行 到 24 点 的 时 候 ， 需 要 进行 数据 库 级 别 的 闪 回 操作 ， 闪 回 全 库 到 1 点 状态 (基于 时 点 或 SCN 的 内 回 ) 。 在 发 起 操作 


后 ， 数 据 库 会 去 寻找 1 点 到 24 点 之 间 的 Flashback 日 志 (该 日 志 是 Flashback 功 能 用 以 记录 数据 块 变化 的 一 种 日 志文 件 ， 它 定期 记录 数据 块 变化 的 “前 像 ”) ， 闪 回 有 变化 的 数据 块 到 其 1 点 的 状态 ， 并 应 有 


档 日 志 信息 来 填补 闪 回 后 数据 块 “ 前 像 ”到 目标 时 点 的 间隔 。 如 果 是 进行 基于 闪 回 点 的 闪 回 操作 ， 其 原理 上 与 基于 时 点 或 SCN 的 闪 回 是 一 样 的 。 


电 


值得 注意 的 是 ，Flashback 功 能 虽然 很 便捷 ， 比 传统 的 数据 库 恢复 方式 要 更 节省 时 间 ， 但 是 其 对 数据 库 的 性 能 影响 也 是 非常 大 的 ， 因 此 对 于 在 线 业 务 应 用 的 数据 库 不 建议 开启 Flashback 功 能 。 


8.1.4 “T-1” 数据库 搭建 


下 面 我 们 通过 一 个 搭建 实例 来 展示 一 下 “T-1” 数 据 库 的 实现 。 值 得 先 提 一 下 的 是 ， 如 果 在 备 库 中 开启 Flashback 功 能 我们 可 以 不 必 全 库 开启 ， 只 需要 开启 基于 有 保障 的 闪 回 点 方式 (Guarantee 


Restore Point) 即 可 ， 这 样 可 以 一 定 程度 上 减少 Flashback 功 能 对 数据 库 造成 的 开销 。 


步骤 1 首先 ， 需 要 在 备 库 上 停止 日 志 应 用 ， 并 创建 一 个 有 保障 的 闪 回 点 open_before。 需 要 注意 的 是 ， 这 个 闪 回 点 一 定 是 在 备份 独立 打开 之 前 创建 的 。 操 作 示 例如 下 : 


SQL> alter database recover managed standby database cancel; 
Database altered. 

SQL> create restore point open before guarantee flashback database; 
Restore point created. 本 


步骤 2 在 主 库 上 需要 将 到 备 库 的 日 志 传 输 暂 停 ， 否 则 当 备 库 独立 打开 后 会 报错 。 暂 停 操作 示例 如 下 : 


SQL> alter system archive log current; 

System altered 

SQL> alter System set lo0g archive dest state 2=defer; 
System altered ky 加 加 和 


步骤 3 激活 备 库 ， 并 且 确 认 备 库 为 最 大 性 能 运行 状态 ， 避 免 对 主 库 造成 影响 ， 最 后 正常 打开 备 库 即 可 。 具 体操 作 如 下 : 


SQL> alter database activate standby database; 

Database altered. 

SQL> alter database set standby database to maximize performance; 
Database altered. 

SQL> alter database open; 

Database altered. 


此 时 ， 备 库 就 与 主 库 分 离开 了 ， 可 以 作为 一 个 独立 的 数据 库 对 外 提供 读 写 服务 。 再 通过 接 下 来 的 步骤 验证 一 下 是 否 可 以 独立 读 写 并 成 功 闪 回 吧 。 


步骤 4 在 主 库 上 创建 一 个 空 的 测试 表 alex_primary， 同 时 在 独立 打开 的 备 库 上 创建 另 一 个 空 的 测试 表 alex_standby， 发 现 主 备 库 都 独立 创建 成 功 且 没有 任何 同步 关系 。 此 时 
1” 交 易 数据 库 。 


@ 主 库 操作 : 


， 备 库 已 经 成 功 转变 为 “T- 


SQL> create table alex.alex Primary (id number, name Varchar2 (10) ) 7 
Table created 

SQL> select owner, table name from dba tables where owner='ALEX'; 
ONNER TABLE NAME 

ALEX ALEX PRIMARY 

ALEX TL 


@ 备 库 操作 : 


SQL> create table alex.alex standby (id number, name Varchar2 (10) ) 7 
Table created 

SQL> select owner, table name from dba tables where owner='ALEX'; 
ONNER TABLE NAME 

ALEX ALEX STANDBY 

ALEX T1 


当 “T-1” 数 据 库 完成 一 个 周期 的 读 写 服务 后 ， 就 要 将 其 闪 回 为 备 库 了 。 通 过 接 下 来 的 步骤 验证 一 下 通过 有 保障 的 闪 回 点 是 否 能 够 成 功 实 现 吧 。 


步骤 5 ”在 主 库 重 新 开启 到 备 库 的 日 志 传 输 ，SQL 语 句 如 下 : 


SQL> alter system set lo0g archive dest state 2=enable; 
System altered 


步骤 6 重启 “T-1” 库 到 mount 状 态 ， 并 将 其 闪 回 到 open_before 闪 回 点 ， 操 作 如 下 : 


open_before 闪 回 点 ， 操 作 如 下 : 

SQL> shutdown immediate 

SQL> startup mount 

SQL> flashback database to restore point open before; 
Flashback complete. 


步 又 7 切换 “T-1” 库 为 备 库 ， 并 再 次 重启 到 mount 状 态 ，SQL 语 句 如 下 : 


SQL> alter database convert to physical standby; 
Database altered. 

SQL> shutdown immediate 

SQL> startup nomount 

SQL> alter database mount standby database; 
Database altered. 


步骤 8 ”在 备 库 验证 没有 出 现 归档 日 志 丢失 之 后 ， 


由 


新 开启 备 库 上 的 日 志 应 用 服务 。 SQL 语句 如 下 : 


SQL> select * from VSarchive gap; 

no rows selected 

SQL> alter database recover managed standby database 
2 disconnect from session; 

Database altered. 


至 此 ， 备 库 就 完成 了 一 个 转变 为 “T-1” 交 易 数 据 库 的 周期 服务 。 在 以 只 读 方 式 打开 后 ， 可 以 验证 到 之 前 在 “T-1” 库 创建 的 表 alex_standby 已 经 不 复 存 在 ， 取 而 代 之 的 是 从 主 库 同 步 过 来 的 
alex_primary 表 。 验 证 查询 如 下 : 


SQL> select owner, table name from dba tables where owner='ALEX'; 
OWNER TABLE NAME 

ALEX ALEX PRIMARY 

ALEX 如 


综 上 所 述 ，“T-1” 交 易 数据 库 并 不 是 Oracle 提 供 的 一 种 数据 库 角 色 ， 而 是 在 Data Guard 中 能 够 独立 打开 ， 提 供 读 写 服务 ， 并 且 能 成 功 闪 回 的 物理 备 库 ， 其 是 一 个 虚拟 出 来 的 角色 概念 。 它 最 大 的 价值 
就 是 实现 生产 数据 库 上 的 业务 分 离 ， 减 少 非 实时 业务 应 用 对 实时 业务 应 用 的 干扰 。 属 于 一 种 变相 解决 实时 应 用 高 并 发 压力 的 方案 。 


8.2 ADG 实 现 读 写 分 离 


以 上 我 们 通过 “T-1” 交 易 数据 库 的 搭建 完成 了 性 能 优化 、 报 表 分 析 、 数 据 采集 等 分 析 系统 从 实时 生产 库 的 分 离 。 此 时 ， 实 时 生产 库 仅 提供 实时 业务 的 服务 支持 ， 是 否 有 一 种 意犹未尽 之 感 呢 ， 能 否 再 进 
行 一 些 应 用 分 离 呢 ? 当然 可 以 ， 在 实时 的 业务 应 用 中 ， 还 是 有 进一步 分 离 的 可 能 的 ， 可 以 将 一 些 实时 的 只 读 应 用 分 离 出 来 。 


然而 ， 对 于 传统 的 Data Guard 和 上 述 的 “T-1” 数 据 库 都 是 无 法 实现 的 ， 其 物理 备 库 虽 然 可 以 以 只 读 方 式 打开 ， 但 与 此 同时 利用 日 志 进行 数据 同步 的 过 程 就 需要 停止 ， 如 果 物 理 备 库 处 于 日 志 应 用 状态 
又 不 能 只 读 打 开 ， 这 就 是 说 日 志 应 用 和 只 读 打开 两 个 状态 不 能 同时 满足 。 很 幸运 的 是 ，Oracle 数 据 库 从 119g 开 始 ， 引 进 了 Active Data Guard (简称 ADG) 功能 ， 这 个 功能 可 以 视 为 传统 Data Guard 的 功能 
强化 ， 其 支持 备 库 在 同步 主 库 数据 的 同时 对 外 提供 只 读 服 务 。 


8.2.1 ADG 架 构 简介 


ADG 是 Oracle 数 据 库 11g 企 业 版 的 选 件 之 一 ， 该 选 件 可 通过 将 资源 密集 型 工作 转载 到 一 个 或 多 个 同步 备份 数据 库 来 提升 数据 库 整体 服务 质量 ， 同 时 它 也 是 需要 额外 收费 的 。 


ADG 的 功能 优势 主要 表现 在 以 下 几 个 方 


回 


“ 物理 备 库 支持 实时 只 读 访问 : ADG 针 对 实时 查询 、 实 时 报表 、 实 时 故障 分 析 等 应 用 提供 物理 备 库 的 只 读 访 问 ， 同 时 可 继续 接收 并 应 用 来 自主 库 的 更 改 日 志 。 


“ 加 快 在 备 库 上 进行 数据 库 备 份 的 速度 : Oracle 从 10g 开 始 引 入 了 块 修改 跟踪 (Block Change Tracking) 技术 ， 来 监控 数据 库 自 上 次 增 量 备份 以 来 修改 了 的 数据 块 ， 这 样 可 以 加 快 增 量 备份 的 速度 ， 但 是 该 
功能 只 能 在 主 库 上 使 用 ， 在 备 库 上 是 不 支持 的 。 在 引入 ADG 后 ， 物 理 备 库 也 可 以 支持 块 修改 跟踪 功能 ， 消 除了 在 生产 主 库 上 执行 备份 引起 的 开销 。 


“ 提高 备 库 日 志 应 用 的 性 能 : ADG 可 以 利用 并 行 技术 进行 日 志 的 应 用 ， 提 高 了 备 库 的 恢复 速度 。 


“T-1” 交 易 数据 库 的 实现 : ADG 与 普通 Data Guard 一 样 ， 同 样 可 以 实现 上 述 介绍 的 “T-1” 交 易 数 据 库 架构 。 


使 用 ADG 来 实现 业务 数据 库 的 读 写 分 离 应 用 也 是 比较 多 样 化 的 ， 如 图 8-4 所 示 ， 在 不 中 断 主 库 到 备份 数据 同步 的 前 提 下 ， 也 可 以 按照 具体 的 查询 需求 分 为 延迟 备 库 和 实时 备 库 。 


延 时 查询 备份 导数 


在 线 应 用 ES 


实时 写 操作 


A 同 风 


实时 故障 分 析 


8-4 ADG 实 现 读 写 分 离 场景 


虽然 ADG 可 以 方便 地 实现 数据 库 的 读 写 分 离 ， 但 也 不 建议 创建 太 多 的 ADG 物 理 备 库 ， 避 免 过 多 的 日 志 传输 引起 生产 主 库 的 压力 和 网 络 负载 的 压力 。 


8.2.2 ”ADG 数 据 库 搭建 


，ADG 数 据 库 也 可 以 当做 普通 Data Guard 来 使 用 ， 只 有 将 其 激活 成 ADG， 才 能 实现 ADG 数 据 库 的 功能 。 


ADG 数 据 库 环境 的 搭建 工作 ， 其 实 跟 普通 的 Data Guard 没 有 什么 


风 
济 


下 面 通过 一 个 实例 来 展示 一 下 如 何 激活 并 使 用 ADG 数 据 库 吧 。 


步骤 1 按照 普通 Data Guard 方 式 搭建 ADG 环 境 ， 在 物理 备 库 上 开启 日 志 应 用 服务 ， 此 时 物理 备份 的 状态 为 “MOUNTED” 。 操 作 过 程 如 下 : 


SQL> alter database recover managed standby database 
2 disconnect from session; 

Database altered. 

SQL> select open mode from v$database; 

OPEN_MODE 


MOUNTED 


此 时 ， 物 理 备 库 是 不 可 用 的 ， 当 发 起 会 话 连接 ， 会 提示 如 下 的 错误 信息 : 


SQL> conn alex@myadg 
ERROR : 
ORA-01033: ORACLE initialization or shutdown in progress 


步骤 2 需要 将 物理 备 库 激 活 为 ADG 备 库 ， 先 要 将 其 切换 到 只 读 状 态 ， 操 作 过 程 如 下 : 


SQL> alter database recover managed standby database cancel; 
Database altered. 

SQL> alter database open read only; 

Database altered. 

SQL> select open mode from v$database; 

OPEN_MODE 


READ ONLY 


步骤 3 ”在 物理 备 库 以 只 读 状态 打开 的 时 候 ， 再 将 其 日 志 应 用 服务 打开 ， 可 以 看 到 备 库 的 状态 变 为 了 “READ ONLY WITH APPLY”， 此 时 ADG 功 能 开启 ， 其 可 以 同时 实现 只 读 访问 和 日 志 应 用 。 操 作 
示例 如 下 : 


SQL> alter database recover managed standby database 
2 disconnect from session; 

Database altered. 

SQL> select open mode from v$database; 

OPEN_MODE a 


READ ONLY WITH APPLY 


在 上 例 中 ， 日 志 应 用 方式 是 延 时 同步 的 ， 在 主 库 发 生 数据 变更 后 ， 其 变更 不 会 立刻 同步 到 备 库 ， 需 要 在 主 库 上 进行 日 志 归档 操 作 才 会 触发 变更 数据 到 备 库 的 同步 。 验 证 过 程 如 下 : 


@ 主 库 上 操作 : 


SQL> insert into alex.alex _ Primary values (11,'alex'); 


SQL> commit; 


SQL> select * from alex.alex primary; 


ID NAME 


@ 备 库 上 查询 : 


SQL> select * from alex.alex primary; 


no rows selected 


@ 主 库 上 操作 : 


SQL> alter system archive log current; 


System altered 


@ 备 库 上 查询 : 


SQL> select * from alex.alex Primary 
ID NAME 


步骤 4 ”要 配置 成 支持 实时 数据 查询 的 ADG 备 库 ， 只 需要 以 实时 日 志 应 用 方式 配置 即 可 : 


SQL> alter database recover managed standby database cancel; 


Database altered. 


SQL> alter database recover managed standby database 
2 using current logfile disconnect from session; 


Database altered. 


SQL> select open mode from v$database; 


OPEN_MODE 


READ ONLY WITH APPLY 


此 时 ， 再 进行 与 步骤 3 中 一 样 的 验证 ,会 发 现 主 库 中 的 数据 变更 立刻 会 同步 到 备 库 的 查询 中 ， 实 时 查询 效果 达成 ， 验 证 示例 如 下 : 


@ 主 库 上 操作 : 


SQL> insert into alex.alex primary values (12,'alex'); 


SQL> commit; 


SQL> select * from alex.alex primary; 


ID NAME 


@ 备 库 上 查询 : 


SQL> select * from alex.alex Primary 


ID NAME 


采用 实时 日 志 应 用 方式 必须 在 备 库 上 创建 备份 重 做 日 志 (Standby Redo Log) ， 每 当日 志 被 写 入 备份 重 做 日 志 时 ， 就 会 触发 恢复 ， 在 备 库 上 立刻 查询 到 从 
的 日 志 切 换 来 触发 。 然 而 ， 所 谓 的 实时 查询 也 只 是 一 种 准 实时 的 方式 ， 网 络 上 的 延 时 和 日 志 应 


8.3 本章 小 结 


纵 观 本 章 ， 主 要 围绕 Data Guard 功 能 介绍 了 “T-1” 交 易 数据 库 和 ADG 数 据 库 两 种 新 型 的 应 


发 挥 积极 作用 。 下 一 章 是 本 书 的 最 后 一 章 ， 将 给 读者 一 个 总 结 性 的 整体 介绍 ， 并 展开 一 些 超出 纯 技术 范围 的 软 技巧 介绍 。 


第 9 章 ”最 佳 实践 


方式 ， 拓 宽 了 Data Guard 功 能 的 使 用 范 


本 身 的 延 时 都 是 不 可 避免 的 ， 同 时 会 在 一 定 程度 上 增加 


,使 


会、 


是 


E 库 的 压力 ， 建 议 非 必要 情况 不 要 开启 实时 日 志 应 


E 库 同步 过 来 的 数据 变更 ， 而 不 必 等 待 主 库 


得 其 不 仅仅 是 典型 容 灾 解 决 方案 ， 更 能 为 解决 高 并 发 问题 


本 来 打算 在 本 章 中 向 大 家 介绍 一 个 综合 性 的 案例 ， 从 架构 和 设计 开始 讲 起 ， 如 何 架 构 、 设 计 和 实现 一 个 真实 的 高 并 发 Oracle 系 统 。 但 是 ， 纠 结 良久 ， 还 是 决定 放弃 。 


在 我 设计 过 的 系统 架构 中 ， 大 凡 在 项 目 初期 ， 大 吵 大 哮 着 会 有 很 大 的 用 户 量 和 很 高 的 并 发 预期 的 ， 结 果 都 是 系统 进行 了 一 两 年 都 没有 什么 数据 库 压力 ， 而 一 些 初期 不 怎么 受 重视 的 系统 ， 在 上 线 一 段 时 


间 后 ， 活 路 用户 行 为 和 并 发 压力 却 陡 增 。 很 多 时 候 ， 系 统 和 数据 库 的 并 发 压力 不 是 在 设计 阶段 可 以 预期 的 ， 其 关键 还 是 取决 于 业务 应 


本 身 和 外 部 的 f 


个 异性 ， 同 时 决定 高 并 发 压力 现象 也 存在 个 异性 。 那 么 ， 设 计 的 架构 也 不 应 该 是 单一 的 形态 ， 因 为 没有 万 能 的 架构 可 以 解决 万 变 的 需求 。 


和 场 行为 。 业 务 行为 的 个 异性 决定 了 数据 库 并 发 行为 的 


数据 库 架 构 的 “最 佳 实践 ”， 其 本 身 就 是 一 个 伪 命 题 ， 即 便 是 通用 性 较 强 的 架构 也 不 可 能 应 对 所 有 的 应 用 场景 。 所 谓 兵 无 常 势 ， 水 无 常 形 ， 架 构 之 妙 ， 存 平一 心 。 在 做 数据 库 架 构 设计 的 时 候 ， 没 有 什 


么 技术 是 最 好 用 的 ， 更 不 必 


因为 别人 成 功 应 用 某 项 技术 解决 了 类 似 的 问题 ， 就 一 定 要 模仿 ， 极 端 化 的 设计 是 要 不 得 的 。 


O 


故而 在 本 章 中 ， 我 将 会 


9.1 术 


向 大 家 分 享 一 些 我 实际 工作 中 的 经 验 总 结 ， 其 中 观点 可 以 借鉴 ， 于 你 而 言 也 许 并 非 “ 最 佳 ”。 


在 本 书 第 1 章 中 已 经 提 及 过 “ 术 ” 与 “ 道 ” 这 两 个 概念 ， 接 下 来 我 们 先 来 阐述 一 下 什么 是 “ 术 ”。 所 谓 “ 术 ”， 在 数据 库 架 构 师 的 概念 中 ， 首 先 应 该 是 技术 ， 也 可 以 称 之 为 专业 技能 ， 本 书 的 第 2 章 到 第 
8 章 都 是 在 阐述 具体 的 技术 内 容 。 


Oracle 数 据 库 在 国内 经 过 十 几 年 的 发 展 和 成 熟 ， 其 技术 应 用 能 力 可 以 说 达到 了 一 个 比较 理想 的 高 度 。 一 位 刚 接触 Oracle 数 据 库 一 两 年 的 新 人 ， 就 能 够 熟练 地 完成 Data Guard 和 RAC 数 据 库 的 搭建 和 SPA 
的 性 能 分 析 ， 基 本 上 实现 了 技术 在 业内 的 扁平 化 。 这 就 好 比 熟 练 掌握 了 功夫 的 套路 ， 但 这 并 不 代表 能 够 运用 得 收 放 自 如 ， 更 不 代表 熟练 心 法 。 


9.1.1 技术 回顾 


在 开始 新 内 容 之 前 ， 我 们 先 来 回顾 一 下 本 书 前 面 的 内 容 吧 。 本 书 讲述 “ 术 ” 的 相关 章节 和 主要 内 容 如 图 9-1 所 示 ， 其 中 包括 : 


: 高 效 B 树 索引 : 索引 设计 、 索 引 优化 ， 以 及 B 树 索引 相关 的 一 些 建议 与 规范 ; 

:高效 表 设计 : 表 设计 、 表 优化 ， 以 及 表 设计 相关 的 一 些 建议 与 规范 

: 查询 优化 器 : 优化 器 规范 、 优 化 器 调 优 、 性 能 分 析 

“ 常见 高 并 发 案例 : 案例 分 析 参 考 ; 

' TimesTen 内 存 数据 库 : 全 面 介绍 一 款 内 存 中 的 数据 库 ， 实 现 并 发 压力 较 大 的 数据 库 的 纵向 扩展 ; 


GoldenGate 构 建 数 据 库 群 : 使 用 DGG 搭 建 异 构 的 数据 集成 平台 ， 实 现 小 核心 大 外 围 的 数据 库 群 体系 ， 对 体系 整体 实现 业务 逻辑 层级 的 横向 拆 分 ; 


" Data Guard 的 妙用 : 对 单个 并 发 压力 较 大 的 库 ， 进 行 单 库 的 业务 逻辑 的 横向 拆 分 。 
-人 » » 
这 9| 设计 


商 效 B 树 索引 
索引 优化 


表 设计 
商 效 表 设计 


表 优 化 


Es 优化 器 规范 


得 询 优化 硕 优化 磺 调 优 


性 能 分 析 


稍 见 局 并 发 案例 案例 参考 


TimesTen 内 存 数据 库 内 存 中 的 数据 库 


GoldenGate 构 建 数据 库 群 数据 库 集成 平台 


Data Guard 的 妙用 业务 横 癌 分 散 


9-1 本 书 关 于 “ 术 ” 的 重点 内 容 


了 解 了 这 些 知识 点 和 内 容 ， 是 否 有 些 零乱 之 感 ， 如 何 使 之 服务 于 具体 的 工作 呢 ， 请 参考 图 9-2， 知 识 点 能 够 串联 并 应 用 才能 称 之 为 知识 体系 ， 本 书 介绍 的 各 个 方面 的 知识 点 都 是 以 业务 需求 为 导向 的 ， 也 
就 是 以 实际 应 用 为 出 发 点 的 ， 实 际 应 用 中 不 常用 的 就 不 介绍 。 


小 务 需 ; > 


Rs 二 
优化 器 规范 | [索引 设计 表 设计 
0 | 
[EN Re 
| 索引 优化 表 优化 
| 优化 器 调 优 
| yD ED EE ED ED ED ED ED ED EE ED ED ED SE ED ED EE ED ED EE ED ED ED ED CD 村 
性 能 分 析 
MM | 
| 数据 库 集成 平台 业务 横向 分 散 I 
> | 


业务 需求 内 存 中 的 数据 库 


图 9-2 ”知识 体系 应 用 流程 


当 有 新 业务 需求 的 时 候 ， 第 一 步 触发 的 就 是 数据 库 建 模 阶 段 ， 包 括 了 表 和 索引 的 设计 。 这 个 阶段 我 们 对 业务 未 来 的 规模 和 压力 是 无 法 准确 预 估 的 ， 但 是 需要 给 予 足够 的 数据 库 纵横 扩展 的 可 能 性 ， 此 时 
就 需要 各 类 规范 (优化 器 规范 、 表 设计 规范 、 索 引 设计 规范 、 对 象 命名 规范 、 数 据 库 架构 规范 等 ) 的 注入 。 


在 完成 设计 后 ， 数 据 库 就 应 该 上 线 使 用 了 ， 其 间 不 可 避免 地 会 发 生 这 样 那样 的 性 能 问题 ， 包 括 高 并 发 导致 的 性 能 问题 。 此 时 ， 在 历史 经 验 和 案例 注入 的 前 提 下 ， 主 要 进行 表 、 索 引 、 优 化 器 相关 的 性 能 
优化 。 


性 能 优化 的 结果 需要 有 一 个 可 量化 的 指标 ， 通 过 各 种 性 能 分 析 的 手段 进行 准确 评估 ， 如 果 能 够 在 Oracle 数 据 库 内 部 解决 的 就 内 部 解决 ， 必 要 时 进行 索引 和 表 的 再 设计 ; 如 果 无 法 内 部 解决 的 ， 就 考虑 数 
据 库 的 纵横 扩展 。 


纵横 扩展 的 手段 有 很 多 ， 通 常 都 是 从 易 到 难 来 逐步 扩展 ， 不 能 一 跳 而 就 。 在 本 书 介绍 的 手段 中 ， 应 该 先 考虑 GoldenGate 和 Data Guard 的 扩展 方式 ， 当 其 不 能 满足 业务 需求 的 时 候 ， 才 考虑 引入 新 型 数 
据 库 技术 ， 这 样 对 于 数据 库 架 构 来 说 才 是 最 稳健 的 ， 不 可 动力 选择 “休克 疗法 ”。 


如 此 一 来 ， 看 似 零 乱 的 知识 点 就 因为 业务 需求 而 有 机 地 组 织 起 来 了 ， 其 中 比较 关键 的 一 点 就 是 各 类 的 规范 。 看 似 枯燥 无 趣 的 规范 ， 却 可 以 让 你 站 在 巨人 的 肩膀 上 去 思考 架构 设计 的 问题 。 


9.1.2 ”规矩 方圆 


我 们 说 做 数据 库 架构 设计 要 尽 可 能 地 做 得 艺术 一 些 ， 要 以 具体 的 业务 需求 为 导向 ， 不 拘泥 于 技术 本 身 ， 但 这 并 不 代表 在 设计 过 程 中 就 可 以 随心 所 欲 了 。 


不 以 规矩 ， 无 以 成 方圆 。 规 矩 也 好 ， 规 范 也 罢 ， 都 是 前 人 经 验 和 教训 的 总 结 ， 可 能 它 会 制约 你 的 能 力 发 挥 ， 可 能 会 束缚 你 的 设计 思想 ， 但 是 一 套 优 秀 的 规范 可 以 使 一 位 初级 架构 师 像 中 级 架构 师 一 样 去 
工作 ， 可 以 使 一 位 中 级 架构 师 像 高 级 架构 师 一 样 去 思考 ， 更 可 以 使 一 位 高 级 架构 师 思考 得 具有 创造 性 。 架 构 师 们 可 以 秉承 共同 的 观点 和 思路 ， 可 以 像 一 个 架构 师 集群 一 样 和 谐 地 工作 。 


对 于 数据 库 架 构 来 说 ， 可 以 由 于 业务 的 不 同 而 存在 个 异性 ， 但 一 套 适用 的 规范 是 不 可 或 缺 的 。 如 图 9-3 所 示 ， 一 套 成 型 的 数据 库 规 范 体系 是 历史 经 验 和 实际 问题 的 沉淀 和 积累 ， 通 过 评审 委员 会 定期 收集 
需求 和 研讨 问题 ， 最 终 形成 一 套 完整 的 规范 体系 ， 并 以 文档 的 形式 输入 ITIL 服 务 体系 ， 之 后 进行 必要 的 推广 和 培训 ， 最 终 用 户 、 开 发 人 员 、DBA 都 可 以 是 推广 和 培训 的 受众 。 其 中 ， 在 文档 形成 和 推广 培训 
过 程 中 反馈 出 来 的 问题 将 成 为 下 一 版 本 规范 制定 的 基础 。 


历史 文档 集 


< 


实际 问题 需求 


数据 库 规范 体系 
操作 维护 | 建 模 开发 规范 。 
一 一 | 命名 规范 || 建 模 规范 
流程 规范 ee [TABTE 9 
[架构 规范 上 < 规范 | VIEW | < pu 
me || INDEX 规范 文档 
_ 其 他 规范 TRIGGER 


图 9-3 ”数据 库 规范 体系 建设 


以 表 的 命名 为 例 ， 在 两 个 不 同 


户 下 同名 的 表 ， 其 业务 含义 也 是 一 样 的 。 相 信 大 家 经 常会 遇 到 这 样 的 情况 ， 这 其 实 是 非常 尴 炊 的 。 对 于 这 样 的 应 


ITIL 服 务 体系 推广 与 培训 


好 


() 
开发 与 用 户 


， 我 们 在 写 SQL 的 时 候 ， 是 不 是 要 包含 进去 用 户 名 


呢 ? 如 果 包 含 ， 关 联 的 程序 代码 编写 就 非常 不 方便 ; 如 果 不 包 含 ， 不 同 的 表 的 数据 量 和 数据 分 布 都 是 不 一 样 的 ，SQL 执 行 计划 就 比较 难 控制 了 ， 特 别 是 通过 SPM 固 化 了 的 执行 计划 ， 很 可 能 出 现 性 能 问题 。 


如 果 我 们 有 表 的 命名 规范 ， 强 制 表 的 命名 需要 明确 表达 实体 数据 对 象 的 业务 意义 ， 这 样 的 问题 就 不 会 存在 了 。 具 体 的 规范 是 : 在 同一 套数 
名 的 表 。 


级 ， 而 不 是 使 用 通用 的 前 后 级 (如 “TBL”， 


“T ”等 ) ， 这 样 基本 可 以 保证 一 个 库 中 没有 和 


居 库 中 ， 表 的 命名 以 能 表达 业务 含义 的 2~ 3 个 字符 作为 前 后 


而 在 索引 的 命名 规范 方面 ， 一 般 索引 名 字 需 要 包含 表 名 的 含义 并 能 反映 相关 字段 名 的 含义 。 这 样 做 有 什么 好 处 呢 ? 一 方面 便于 阅读 ， 索 引 对 应 的 表 和 字段 一 目 了 然 。 另 一 方面 ， 对 性 能 也 是 有 帮助 的 ， 


如 果 我 们 需要 定位 一 个 表 对 应 的 索引 和 索引 列 ， 我 们 需要 联 立 DBA_TABLES、DBA_INDEXES、DBA_IND_COLS 三 个 数据 字典 视 


关键 字 进行 筛选 即 可 。 


9.1.3 ”穿越 之 眼 


， 但 更 为 


处 ， 因 为 行业 发 展 速度 太 快 了 。 


借用 现下 一 个 比较 流行 的 词 
情 一 样 横 空 出 世 ， 不 得 不 一 步 一 个 脚印 地 去 做 。 


天 做 到 的 成 绩 可 以 是 我 们 明天 的 努力 目标 ， 那 么 他 们 今天 的 成 绩 就 是 我 们 穿越 的 着 眼 点 。 不 论 是 风险 控制 ， 还 是 成 本 控制 方面 ， 这 种 穿越 都 将 是 最 具有 实 操 性 的 。 同 时 ， 需 要 注意 的 是 不 要 盲目 穿越 。 虽 


的 是 及 时 更 新 。 优 秀 的 规范 就 像 一 把 双 刃 剑 ， 一 方面 可 以 简 自 


说 “他 山 之 石 可 以 攻 玉 ”， 但 也 要 做 好 借鉴 的 可 行 性 分 析 。 


9.2 道 


“ 道 ” 的 概念 是 有 别 于 “ 术 ” 的 ， 它 不 在 于 技术 的 本 身 ， 而 在 于 技术 之 外 的 一 些 技能 ， 
么 “ 道 ” 就 是 武功 心 法 ;如果 说 “ 术 ” 是 做 事 ， 那 么 “ 道 ”就 是 做 人 。“ 术 ”在 于 学 习 和 积累 ， 


9.2.1 数据 库 架 构 师 


在 第 1 章 中 ， 我 们 卖 了 一 个 关子 ， 什 么 是 数据 库 架 构 师 的 “ 道 ”， 这 里 就 来 解 开 这 个 关子 。 在 说 “ 道 ”之 前 ， 先 来 说 说 什么 是 数据 库 架 构 师 (Database Architect) 吧 。 


“他 们 的 工作 太 虚 了 ， 每 天 不 知道 他 们 在 干 些 什么 ………” 


“数据 库 管 理 员 做 得 资深 一 些 ， 就 是 数据 库 架构 师 了 。” 


“公司 为 了 招 一 些 很 牛 的 人 来 ， 设 置 的 一 个 比较 虚 的 职位 吧 ， 


“数据 库 架 构 师 ? 他 们 只 是 每 天 在 走 流程 ， 


这 个 我 也 能 做 。” 


或 者 说 是 软 实力 。 如 果 说 “ 术 ” 是 专业 技能 ， 那 么 
“ 道 ” 则 在 于 思考 和 领悟 。 


虽然 工作 本 身 不 能 穿越 ， 但 是 设计 思想 和 眼光 可 以 穿越 ， 不 仅 可 以 自我 穿越 ， 还 可 以 从 其 他 人 和 企业 身上 寻求 穿越 。 比 如 ， 在 某 个 行业 的 某 个 领域 中 ， 肯 定 会 有 一 到 两 个 企业 做 得 出 类 拔 萃 的 ， 他 们 


地 实现 “填空 式 ” 设 计 ， 进 而 简化 运 维 ; 另 一 方面 不 能 及 时 更 新 就 会 导致 规范 本 身 的 “过 时 ”。 


技能 ; 


因为 你 说 找 数据 库 管理 员 ， 没 有 资深 的 人 愿意 来 。” 


类 似 以 上 对 数据 库 架 构 师 的 评价 应 该 不 在 少数 ， 大 凡 说 到 架构 师 ， 都 容易 与 概念 、 虚 职 等 联系 起 来 ， 而 事实 上 ， 在 不 少 公司 也 确实 如 此 。 


通常 来 说 ,数据库 架构 师 应 该 包含 以 下 两 层 合 义 : 


如 果 说 “ 术 ” 是 武功 套路 ， 那 


“ 数据 库 技 术 的 架构 设计 。 这 方面 合 义 通常 是 被 大 家 所 熟知 的 ， 主 要 侧重 于 数据 库 技术 方面 的 设计 与 把 关 ， 可 以 是 运 维 方 面 的 专家 ， 能 力 强 的 运 维 DBA 可 以 升级 为 该 层面 的 数据 库 架构 师 。 


图 ， 而 有 了 命名 规范 ， 只 需要 查询 DBA_INDEXES， 在 WHERE 子 句 加 个 LIKE 


一 词 对 于 IT 行业 来 说 是 再 熟悉 不 过 的 了 。 大 凡 做 上 T 的 都 会 有 一 个 顾虑 ， 就 是 不 知道 什么 时 候 ， 自 己 熟悉 的 技术 就 会 “过 时 ” ， 从 而 不 断 地 学 习 新 的 技术 知识 ， 这 也 是 与 其 他 行业 相 比 最 无 奈 之 


“穿越 ”， 以 此 来 形容 规范 维护 和 技术 积累 是 再 合适 不 过 的 。 我 们 不 仅 要 向 后 “穿越 ” ， 更 需要 向 前 “穿越 ”， 但 非常 遗憾 的 是 ， 数 据 库 架 构 的 设计 工作 不 会 像 小 说 剧 


公 
今 


“ 数据 本 身 的 架构 设计 。 数 据 库 只 是 数据 的 一 个 载体 ， 对 于 数据 库 来 说 ， 数 据 是 没有 任何 含义 的 ， 然 而 数据 本 身 对 于 应 用 和 业务 来 说 意义 非凡 ， 同 样 是 数据 库 架 构 师 需要 了 解 和 把 控 的 。 这 方面 的 工 
作 ， 数 据 库 架 构 师 主要 负责 与 业务 和 开发 部 门 沟通 ， 明 确 需求 ， 设 计 更 为 合理 的 架构 ， 该 层面 的 含义 更 适合 于 开发 DBA 的 升级 路 线 。 


然而 ， 数 据 库 架构 师 并 不 是 开发 DBA 和 运 维 DBA 的 唯一 升级 目标 ， 也 不 是 每 个 DBA 都 应 该 升级 为 架构 师 。 一 位 真正 意义 上 的 数据 库 架 构 师 不 仅 需 要 “ 术 ” 方 面 的 造 齐 ， 更 需要 “ 道 ”方面 的 修养 。 


9.2.2 沟通 之 道 


说 到 数据 库 架 构 师 的 “ 道 ”， 其 中 最 重要 的 是 什么 呢 ? 答案 可 以 说 是 仁者 见 仁 智 者 见 智 。“ 道 ”不 同 于 “ 术 ”， 对 于 这 个 问题 根本 没有 标准 答案 ， 有 的 只 是 每 个 人 不 同 的 领悟 和 观点 。 而 在 我 看 来 ， 其 
中 最 重要 的 应 该 是 沟通 之 道 。 


“三 流 的 沟通 靠 阅 ， 二 流 的 沟通 靠 听 ， 一 流 的 沟通 靠 问 。” 这 个 说 法 ， 想 必 大 家 都 是 很 熟悉 的 了 ， 但 是 它 只 是 表达 了 一 个 沟通 过 程 中 的 技巧 ， 并 没有 说 清楚 应 该 如 何 展开 沟通 。 我 们 可 以 粗略 地 将 沟通 
过 程 分 为 以 下 三 个 阶段 : 


' 沟通 规划 阶段 ; 
“ 沟通 进行 阶段 ; 


“ 沟通 后 续 阶段 。 


在 这 三 个 阶段 中 ， 很 多 人 往往 只 关注 了 沟通 进行 阶段 ， 结 果 就 可 想 而 知 了 ， 失 败 或 低 效 。 其 实 ， 最 重要 的 应 该 是 沟通 规划 阶段 ， 它 是 保证 沟通 能 够 高 效 完成 的 基础 。 


1. 沟 通 规 划 阶 段 


三 军 未 动 ， 粮 草 先 行 。 在 沟通 发 起 之 前 ， 我 们 需要 先 明确 以 下 几 个 问题 : 
:为 什么 要 沟通 ? 

”和 谁 沟通 ? 

: 如 何 沟通 ? 


(1) 为 什么 要 沟通 


也 就 是 沟通 的 目的 是 什么 。 我 们 做 事情 都 是 以 目标 为 导向 的 ， 沟 通 只 是 一 种 手段 ， 是 为 了 达成 某 种 目的 而 进行 的 ， 而 不 是 为 了 沟通 而 去 沟通 。 这 个 目标 可 以 是 沟通 的 目标 ， 也 可 以 是 项 目 或 任务 阶段 性 
的 目标 。 


(2) 和 谁 沟通 


这 往往 是 非常 关键 的 一 个 问题 。 可 能 有 人 会 质疑 这 个 都 不 知道 还 谈 什 么 沟通 呢 ? 但 是 ， 在 沟通 之 前 ， 你 确实 思考 并 合理 规划 过 吗 ? 我 们 说 沟通 是 为 了 达成 某 种 目的 ， 那 么 与 这 个 目的 达成 有 关联 的 人 都 
可 能 会 是 沟通 的 对 象 。 沟 通 的 对 象 我 们 称 之 为 干系 人 ， 他 们 是 积极 参与 或 其 利益 可 能 受到 相关 联 的 积极 或 消极 影响 的 个 人 或 组 织 (如 客户 、 执 行 组 织 或 公众 ) 。 然 而 ,满足 这 个 要 求 的 人 通常 会 很 多 ， 这 就 
需要 对 其 进行 分 类 管理 ， 有 区 别 有 针 对 性 地 对 待 。 


FF 系 人 管理 的 方式 有 很 多 种 ， 其 中 最 关键 的 还 是 要 进行 关键 干系 人 的 识别 ， 因 为 这 直接 关系 到 沟通 的 结果 。 如 图 9-4 所 示 的 沟通 影响 力矩 阵 ， 纵 坐标 为 权力 ， 横 坐标 为 支持 度 ， 并 将 其 分 为 四 个 象限 ， 将 
干系 人 按照 权力 和 支持 度 的 关系 分 别 填 入 四 个 象限 合适 的 位 置 中 。 再 按照 象限 的 区 别 来 具体 分 析 一 下 : 


4- 猴 子 


文 持 度 


“ 在 第 1 象限 中 ， 这 部 分 干系 人 权力 很 大 ， 可 能 会 直接 左右 目标 是 否 能 够 达成 ， 而 且 他 们 抱 着 支持 的 态度 ， 具 有 积极 的 影响 力 。 固 此 这 部 分 干系 人 应 该 定位 为 关键 干系 人 ， 并 且 需 要 努力 多 沟通 多 争取 
的 。 用 一 种 动物 来 形容 ， 应 该 是 老虎 。 


图 9-4 ”沟通 影响 力 算 阵 


. 在 第 2 象限 中 ， 这 部 分 干系 人 权力 也 很 大 ， 也 会 直接 左右 目标 成 败 ， 他 们 也 是 关键 干系 人 ， 但 他 们 抱 有 不 支持 的 态度 ， 起 着 消极 的 影响 。 对 于 这 类 关键 干系 人 ， 应 该 敦 而 远 之 ， 仅 做 必要 的 沟通 即 可 。 
用 一 种 动物 来 形容 ， 应 该 是 蛇 。 


-在 第 3 象限 中 ， 这 部 分 干系 人 权力 不 大 ， 也 不 关注 不 支持 。 我 们 定义 其 为 “局 外 人 ” ( 非 关键 干系 人 ) ， 对 其 可 持 无 视 态度 ， 只 需要 保持 最 基本 的 消息 传达 即 可 。 用 一 种 动物 来 形容 ， 应 该 是 蚂蚁。 


“ 在 第 4 象限 中 ， 这 部 分 干系 人 虽然 权力 不 大 ， 但 是 非常 支持 你 ， 也 起 着 积极 的 作用 ， 间 接 左 右 着 目标 的 成 败 ， 是 需要 努力 争取 和 沟通 的 关键 干系 人 。 用 一 种 动物 来 形容 ， 应 该 是 猴子 ， 他 们 通常 是 项 目 
或 任务 的 团队 成 员 ， 为 了 目标 的 达成 ， 像 猴子 一 样 忙 碌 得 上 足下 跳 。 


(3) 如 何 沟通 


此 时 最 关注 的 应 该 是 沟通 的 方法 和 手段 ， 或 者 说 是 沟通 的 媒介 。 如 图 9-5 所 示 ， 是 一 个 基本 的 沟通 模型 ， 通 过 关键 干系 人 的 识别 ， 我 们 可 以 明确 沟通 过 程 中 信息 的 发 送 方 和 接收 方 ， 每 个 人 每 一 次 对 信息 
的 接收 和 发 送 都 会 有 一 个 解码 和 编码 的 过 程 ， 信 息 在 干系 人 之 间 通 过 媒介 来 传输 ， 其 过 程 中 又 受到 外 界 噪音 的 干扰 。 


图 9-5 ”基本 沟通 模型 


在 沟通 过 程 中 ， 有 以 下 三 要 素 需要 合理 把 握 。 


“ 编码 和 解码 : 每 个 人 的 性 格 和 对 事务 的 认识 方式 都 是 不 一 样 的 ， 其 沟通 的 表达 方式 也 就 存在 差异 。 相 同 的 信息 由 不 同人 表达 ， 可 能 出 现 不 一 样 的 效果 ， 这 个 就 是 编码 差异 ; 相同 的 表达 由 不 同人 接 
收 ， 同 样 可 能 出 现 不 一 样 的 结果 ， 这 个 则 是 解码 差异 。 在 沟通 过 程 中 ， 需 要 规避 这 些 内 部 因素 的 干扰 。 


“ 唆 声 : 除了 内 部 因素 的 干扰 ， 在 信息 传输 过 程 中 ， 还 会 受到 外 部 因素 的 干扰 (如 新 技术 、 跨 界 沟通 等 ) 。 


“媒介: 用 来 传递 信息 的 方式 ， 包 括 正式 沟通 方式 (如 会 议 、 书 面 报告 、 正 式 邮件 等 ) 和 非 正式 沟通 方式 (如 备忘录 、 电 话 、 单 独 面 对 面 、 非 正式 邮件 等 ) 。 
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的 则 是 沟通 的 媒介 ， 正 确 的 沟通 媒介 的 选择 可 以 减少 信息 传输 过 程 中 的 噪音 干扰 。 避 免 信息 的 衰减 ， 降 低 信息 在 编码 和 解码 阶段 造成 的 不 必要 的 误 读 。 


在 这 三 要 素 当 中 ， 最 有 


2. 沟 通 进行 阶段 


沟通 之 所 以 是 “ 道 ”， 而 不 是 “ 术 ”， 是 因为 它 的 不 确定 性 。 在 沟通 规划 后 ， 对 于 某 些 人 群 可 能 获得 到 很 好 的 沟通 效果 ， 对 于 某 些 人 可 能 不 能 ， 甚 至 可 能 因为 沟通 对 象 当时 心情 的 不 同 也 会 出 现 不 同 的 
结果 。 这 些 都 需要 在 沟通 进行 阶段 随机 应 变 地 把 握 。 


前 面 说 到 的 在 沟通 过 程 中 的 “说 ”、“ 听 ”、“ 问 ”， 都 只 是 沟通 的 一 种 手段 ， 并 无 谁 优 谁 劣 之 说 ， 关 键 在 于 对 具体 沟通 对 象 的 适用 性 ， 其 目的 都 是 引导 沟通 对 象 朝 着 规划 阶段 预期 的 目标 靠拢 ， 并 在 
靠拢 过 程 中 建立 起 一 定 程度 上 的 信任 关系 。 
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信任 关系 的 建立 往往 是 沟通 的 一 个 重要 目标 ， 能 为 进一步 的 沟通 打下 良好 的 基础 ， 在 一 定 程度 上 牺牲 一 些 预期 目标 来 获取 信任 关系 也 是 值得 的 。 这 种 信任 关系 有 的 时 候 也 会 被 称 为 “私交 ”。 信 任 关 系 
的 建立 需要 注意 以 下 几 个 方面 : 


“ 互利 共 赢 : 沟通 双方 应 该 都 能 够 换 位 思考 ， 建 立 利益 共同 点 ， 尽 量 避 免 动 辑 以 某 某 领 导 之 言 相 要 挟 。 


“ 说 到 做 到 : 承诺 过 的 事情 一 定 要 做 到 ， 不 能 做 到 的 ， 事 前 要 言明 ， 尽 量 避 免 动 辆 就 开 空头 支票 。 


“ 不 要 说 说 : 不 论 是 恶意 的 谎言 还 是 善意 的 谎言 ， 都 会 让 对 方 觉得 你 不 是 一 个 可 以 信赖 的 人 。 


: 信息 准确 : 沟通 内 容 只 说 有 关联 的 且 不 遗漏 重要 的 细节 。 


“ 保守 秘密 : 不 说 别人 的 闲话 ， 不 搬 弄 是 非 ， 不 泄露 别人 的 秘密 。 


沟通 过 程 不 但 要 注意 技巧 ， 更 需要 进行 人 格 品质 的 树立 ， 可 以 毫 不 夸张 地 说 : “沟通 成 功 与 否 ， 三 分 看 技巧 ， 七 分 看 人 品 。” 


3 .沟通 后 续 阶段 


一 次 沟通 过 程 完 成 ， 并 不 意味 着 一 个 沟通 周期 的 结束 ， 还 需要 后 续 的 绩效 报告 和 信息 发 布 。 比 如 ， 在 一 次 正式 会 议 之 后 ， 会 议 讨论 的 主要 议题 需要 以 会 议 纪 要 的 形式 进行 信息 发 布 ， 在 会 议 上 要 求 持续 
跟 进 的 事宜 ， 需 要 定期 或 不 定期 地 以 绩效 报告 的 形式 发 布 给 所 有 关键 干系 人 ; 在 会 议 中 尚未 解决 的 问题 ， 需 要 在 会 后 进行 分 析 并 制定 下 一 次 的 沟通 计划 ， 准 备 下 一 个 沟通 周期 。 


总 体 来 看 ， 数 据 库 架构 师 一 方面 要 学 会 高 超 的 沟通 之 道 ， 另 一 方面 也 要 钻研 更 为 简洁 更 为 廉价 的 数据 库 架 构 实现 技术 。“ 道 ”与 “ 术 ” 对 一 位 数据 库 架 构 师 来 说 是 同样 重要 的 ， 重 “ 术 ” 而 轻 “ 道 ”， 
势必 造成 只 知道 埋头 工作 ， 进 而 崇尚 加 班 ， 美 其 名 日 “加 班 文化 ”和 “奉献 精神 ”; 重 “ 道 ”而 轻 “ 术 ′”， 则 会 导致 夺 夺 其 谈 成 风 ， 只 知道 提出 看 似 高 深 实则 不 着 边际 的 问题 ， 飘 对 然 无 法 落地 。 
“ 道 ” 与“ 术 ” 之 间 需 要 达到 一 种 平衡 ， 是 一 种 艺术 与 技术 的 平衡 ， 是 中 国 自古 崇尚 的 中 庸 之 道 的 平衡 。 
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罗贯中 在 《三 国 演义 》 中 说 道 : “话说 天 下 大 势 ， 分 久 必 合 ， 合 久 必 分 。” 孙 中 山 先生 也 曾经 感慨 : “天 下 大 势 ， 浩 浩荡 荡 ， 顺 之 者 昌 ， 逆 之 者 亡 。” 对 于 宏观 世界 来 说 ， 往 往 都 是 时 势 造就 英雄 人 
物 ， 英 雄 人 物 再 引领 世界 形势 的 发 展 。 


而 在 数据 库 的 微观 世界 里 ， 也 有 其 大 势 所 向 ， 也 有 其 代表 性 的 英雄 信物。 数据 库 发 展 的 趋势 从 早期 的 关系 型 数据 库 一 家 独 大 ， 到 | 现 如 今 的 群 奴 割据， 无 不 说 明了 潮流 的 变化 ， 而 在 其 发 展 的 潮流 中 ， 也 
有 很 多 企业 和 个 人 站 到 浪潮 之 刻 ， 引 领 着 行业 的 发 展 。 


在 实际 的 工作 中 ， 我 们 也 在 不 停 咨询 和 被 咨询 着 : “你 们 这 个 是 怎么 来 实现 的 ?你 们 这 样 的 架构 遇 到 什么 问题 吗 ?.…” 不 论 是 学 习 还 是 被 学 习 的 过 程 ， 都 是 一 个 顺势 而 为 的 过 程 ， 即 便 是 做 得 再 好 的 企 
业 和 个 人 都 有 其 不 足 之 处 ， 多 借鉴 别人 的 成 功 经 验 ， 多 借助 行业 发 展 之 势 ， 必 然 可 以 做 到 事半功倍 。 


然而 ， 在 挺进 行业 应 用 中 数一数二 的 地 位 后 ， 也 会 存在 一 些 比较 尴 炊 的 情况 ， 企 业经 年 累 月 使 用 下 来 的 数据 库 传统 架构 ， 会 受到 一 些 新 型 数据 库 技 术 和 新 架构 方式 的 挑战 。 面 临 技术 创新 和 固 步 发 展 的 
选择 ， 如 果 采 用 “休克 疗法 ”， 进 行 全 盘 蔡 换 ， 显 然 不 是 谁 都 能 接受 得 了 这 份 阵痛 ， 如 果 视 而 不 见 ， 又 会 失去 先 机 。 航 母 转弯 还 是 需要 充分 的 准备 时 间 来 进行 试点 的 ， 然 后 以 点 及 面 逐步 展开 。 
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有 眼下 最 火热 的 不 外 乎 大 数据 、 云 平台 、 互 联网 金融 等 概念 ， 不 论 是 企业 还 是 个 人 对 这 些 概念 性 的 技术 无 不 趋 之 若 鳌 ， 更 有 甚 者 在 数据 总 量 不 足 几 个 TB 的 情况 下 ， 就 开始 搞 大 数据 分 析 了 ， 美 其 名 日 “不 
能 输 在 起 跑 线 上 ”。 顺势 而 为 固然 重要 ， 但 也 需要 自我 的 合理 定位 和 预 估 ， 量 力 而 行 ， 避 免 东 施 效 客 的 结果 。 


9.4 本章 小 结 


最 后 总 结 一 下 ， 本 书 通 过 “内 政 篇 ”和 “纵横 篇 ”两 个 部 分 的 内 容 介绍 ， 向 大 家 分 享 了 我 在 解决 高 并 发 问题 方面 和 数据 库 架 构 设计 方面 的 一 些 学 习 、 思 考 和 实践 所 得 。 期 望 在 “ 术 ” 的 分 享 的 同时 ， 共 
同 领悟 “ 道 ” 的 玄妙 ， 然 后 顺 “ 势 ”而 为 ， 必 能 对 数据 库 架 构 设 计 成 竹 于 胸 ， 真 正 做 到 大 道 至 简 。 


本 书 内 容 与 观点 不 足 之 处 ， 望 请 芽 正 。 


